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Standardisation  for  C2-Simulation  Interoperation 

(STO-TR-MSG-085) 

Executive  Summary 

Building  technical  interoperability  standards  is  a  complex  and  time-consuming  process.  Command  and 
Control  to  Simulation  (C2S1M)  interoperability  standardization  efforts  have  been  underway  for  nearly  a 
decade  within  the  Simulation  Interoperability  Standards  Organization  (S1SO).  Under  the  NATO  STO 
umbrella,  in  parallel  and  often  in  concert  with  S1SO,  several  Technical  Groups  have  been  formed  to  assist  in 
the  validation  and  development  of  proposed  C2S1M  interoperability  standards.  From  2004  to  2005  ET-016 
considered  the  feasibility  of  the  Battle  Management  Language  (BML)  in  support  of  military  enterprise 
activities  such  as  Command  Post  training.  From  2006  to  2010,  MSG-048  performed  preliminary  analyses 
and  performed  a  series  experiments  and  thus  was  able  to  provide  an  initial  set  of  requirements  and 
recommendations  for  subsequent  BML  standardization  efforts  and  also  considered  the  use  of  the  Military 
Scenario  Definition  Language  (MSDL)  for  scenario  initialization.  In  2013,  MSG-048  received  the  NATO 
Scientific  Achievement  Award  for  this  work. 

The  results  of  the  follow-on  activity  to  MSG-048,  the  MSG-085  TA  initiated  in  2010,  and  thanks  largely  to 
significant  involvement  from  the  operational  community,  have  established  a  clearer  scope  and  refined  set  of 
operational  and  technical  requirements  for  C2S1M  interoperability.  The  proof  of  concept  has  been 
demonstrated  by  MSG-085.  In  addition  to  work  with  the  operational  community,  there  is  much  technical 
effort  remaining  to  improve  C2S1M.  Both  MSDL  and  C-BML  need  to  have  a  next  generation  developed  to 
facilitate  both  their  working  together  and  the  scope  of  the  interoperability  they  are  able  to  achieve.  MSDL 
should  meet  the  needs  of  a  wide  range  of  national  and  NATO  systems,  while  C-BML  should  improve  both 
the  sophistication  of  what  it  can  represent  and  ease  of  using  it  to  represent  sophisticated  situations. 

As  MSDL  and  C-BML  move  forward,  there  is  a  growing  consensus  among  stakeholders  to  merge  these 
two  activities  to  generate  a  unified,  more  manageable  and  easier  to  deploy  C2SIM  interoperability  solution. 
Toward  this  goal,  MSG-085  already  has  launched  the  Scenario  INitialization  and  Execution  (S1NEX) 
initiative,  an  iterative,  systems  engineering  approach  to  develop  technical  interoperability  standards.  S1NEX 
proposes  a  sustainable,  extensible  process  and  production  chain  for  building,  maintaining  and  evolving 
C2S1M  Interoperability  solutions.  The  proposed  S1NEX  tool  set  is  based  on  existing  products  from  the 
Multi-lateral  Interoperability  Programme  (M1P)  and  the  builds  on  the  M1P  Information  Model  (M1M) 
currently  being  finalized  by  the  MIP.  The  results  obtained  thus  far  from  the  SINEX  initiative  have  led  to 
interest  in  applying  a  rationalized  systems  engineering  approach  to  produce  an  operational  relevant, 
technically  mature,  unified  C-BML/MSDL  standard. 
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Synthese 

L’elaboration  des  standards  d’interoperabilite  est  un  processus  complexe  et  long.  Les  travaux  pour  la 
standardisation  de  l’interoperabilite  entre  les  systemes  de  commandement  et  de  conduite  et  la  simulation 
(C2S1M)  ont  debute  il  y  a  une  dizaine  d’annees  au  titre  de  1’ organisation  des  standards  pour  Tinteroperabilite 
des  simulations  ( Simulation  Interoperability  Standards  Organization,  SISO).  Sous  l’egide  de  1’ Organisation 
pour  la  Science  et  la  Technologie  de  l’OTAN  (NATO  STO),  en  parallele  et  souvent  de  concert  avec  le  SISO, 
plusieurs  groupes  techniques  ont  ete  crees  pour  accompagner  la  validation  et  le  developpement  des  standards 
d’interoperabilite  C2S1M.  Entre  2004  et  2005,  Tactivite  exploratoire,  ET-016,  a  etudie  la  faisabilite  du 
«  Battle  Management  Language  »  (BML)  pour  les  activites  militaires,  cornme  par  exemple  l’entrainement 
des  postes  de  commandement.  De  2006  a  2010,  Tactivite  technique  MSG-048  a  conduit  des  etudes 
preliminaries  et  a  mene  de  nombreuses  experimentations  ayant  permis  d’obtenir  un  premier  ensemble 
d’exigences  et  de  recommandations  pour  les  travaux  de  standardisation  du  BML.  Le  MSG-048  a  egalement 
recommande,  pour  1’ initialisation  des  scenarios,  l’emploi  du  « Military  Scenario  Definition  Language  » 
(MSDL).  En  2013,  Tactivite  technique  MSG-048  a  regu  le  «  NATO  Scientific  Achievement  Award  »  pour  le 
travail  realise. 

L’activite  technique  MSG-085  lancee  en  2010  dans  la  continuite  du  MSG-048  a  permis,  grace  notamment  a 
la  contribution  de  la  communaute  operationnelle,  de  consolider  le  besoin  et  d’approfondir  un  ensemble 
d’exigences  operationnelles  relatives  a  l’interoperabilite  C2S1M.  Le  MSG-085  a  demontre  la  faisabilite  du 
concept.  Au-dela  du  travail  mene  avec  la  communaute  operationnelle,  de  nombreux  travaux  techniques 
necessitent  d’etre  realises  pour  ameliorer  la  connexion  C2S1M.  L’emploi  conjoint  des  standards  MSDL  et 
C-BML  devra  a  Tavenir  etre  facilite.  La  nouvelle  version  de  ces  standards  indiquera  precisement  le  besoin 
operationnel  couvert.  D’ autre  part,  MSDL  devra  s’ adapter  a  un  grand  nombre  de  systemes  nationaux  et  de 
l’OTAN  et  Tutilisation  de  C-BML  devra  etre  simplifiee  et  etre  adaptee  pour  representer  des  situations 
complexes. 

Bien  que  les  standards  MSDL  et  C-BML  continuent  d’evoluer,  les  contributeurs  s’accordent  desormais  pour 
fusionner  ces  deux  activites  afin  de  produire  une  solution  unique  plus  facile  a  deployer  et  evolutive. 
Pour  cela,  le  MSG-085  a  elabore  une  approche  iterative  selon  les  principes  de  Pingenierie  des  systemes 
pour  la  production  de  standards  d’interoperabilite.  Cette  approche,  identifiee  sous  le  nom  de  SINEX, 
pour  Scenario  INitialization  and  Execution,  propose  un  processus  viable  et  evolutif  ainsi  qu’une  chaine 
de  production  pour  Telaboration,  revolution  et  la  maintenance  des  solutions  d’interoperabilite 
C2S1M.  Les  dispositifs  experimentaux  SINEX  sont  congus  a  partir  des  outils  realises  par  le  «  Multi-lateral 
Interoperability  Programme  »  (M1P)  pour  la  realisation  du  «  MIP  Information  Model  »  (M1M).  Les  resultats 
obtenus  a  ce  jour  ont  suscite  Tinteret.  En  effet,  Tapproche  permettra  de  produire  un  standard  operationnel 
approprie  et  techniquement  robuste,  reunissant  C-BML  et  MSDL. 
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This  is  the  final  report  of  the  MSG-085  Technical  Activity  (TA),  Standardization  for  C2-Simulation 
Interoperation.  Its  intended  audience  is  the  NATO  technical  community,  in  particular,  those  working  in  the 
domains  of  Command  and  Control  (C2)  and  Modelling  and  Simulation  (M&S). 

This  document  describes  the  work  and  findings  of  the  MSG-085  TA  that  is  a  follow-on  activity  to  MSG-048. 
The  background  for  MSG-048  is  largely  documented  in  reports  related  to  the  MSG-079  workshop  evaluation 
report  and  MSG-048  final  report  [1],  [6]. 

1.1  DOCUMENT  OVERVIEW 

This  report  is  structured  as  follows: 

•  Introduction  (Chapter  1); 

•  MSG-085  Overview  (Chapter  2); 

•  C2-Simulation  Interoperation  Requirements  (Chapter  3); 

•  Use  of  the  Multi-lateral  Interoperability  Programme  Products  (Chapter  4); 

•  MSG-085  Experimentation  Events,  Workshops  and  Conferences  (Chapter  5); 

•  Lessons  Identified  and  Lessons  Learned  (Chapter  6); 

•  Conclusions  and  Recommendations  (Chapter  7);  and 

•  References  (Chapter  8). 


1.2  WHY  STANDARDIZE  C2SIM  INTEROPERABILITY? 


This  chapter  provides  a  concise  description  of  the  main  motivation  behind  establishing  standards  for 
C2-Simulation  (C2S1M)  interoperation. 


C2-simulation  interoperation  supports 
key  military  areas  of  interest: 

•  Force  Readiness; 

•  Support  for  Operations;  and 

•  Future  Capabilities  Development 


Concept  Development 
.t  Experimentation 
Acquisition 

Training,  Mission  Rehearsal 
Decision  Support 


Standardizing  C2-simulation  interoperation 
provides  the  following  benefits: 

•  Enhanced  realism  &  overall  effectiveness 

•  Decreased  cost  &  workload 

•  Reduced  preparation  time 


Figure  1-1:  C2-Simulation  Interoperability  Standardization  Benefits. 
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Interoperation  among  C2  and  simulation  systems  is  a  common  and  significant  theme  in  the  transformation  of 
modem  military  forces.  It  is  required  to  support  the  military  enterprise  in  the  execution  of  business  activities  and 
mission  threads  such  as  operational  training,  information  sharing  and  decision  support.  This  requirement  implies 
the  ability  to  seamlessly  integrate  C2  systems  and  simulation  systems  and  to  provide  the  means  for  a  meaningful 
and  unambiguous  information  exchange.  C2SIM  interoperation  applies  to  systems-of-systems  functioning 
toward  a  common  goal  at  different  levels: 

1)  Within  services; 

2)  Across  services  (i.e.  joint);  and 

3)  Across  Nations  in  a  multi-national  or  coalition  context. 

Furthermore,  the  advent  of  autonomous  Unmanned  Vehicle  Systems  (UVS)  has  led  to  requirements  for 
increased  interoperation  among  C2  systems  and  the  emerging  category  of  robotic  forces.  The  increasing 
employment  of  unmanned  systems  creates  the  need  to  develop  and  validate  new  concepts  of  operation  and 
therefore  the  need  for  experimentation  capabilities.  The  requirements  for  communication  between  C2  systems 
and  robotic  systems  are  similar  in  many  ways  to  those  for  communication  between  C2  systems  and  simulation 
systems. 

In  such  a  “systems-of-systems”  environment,  the  control  of  one  system  by  another  requires  an  unambiguous, 
automated  mechanism  wherein  C2  and  M&S  concepts  can  be  linked  in  an  effective  and  open  manner. 
Furthermore,  stakeholders  have  recognized  the  importance  of  establishing  an  internationally  accepted  standard 
that  provides  for  a  system-independent  language  and  protocols.  The  MSG-048  Technical  Activity  explored  the 
technical  feasibility  of  a  “Battle  Management  Language”  (BML)  as  a  component  of  an  open  framework  to  link 
C2  systems  and  M&S  or  robotic  systems  in  the  NATO  context  [1].  BML  is  an  unambiguous  language  used  to 
command  and  control  forces  and  systems  conducting  military  operations.  BML  is  being  developed  as  a 
standard  representation  and  means  for  communicating  digitized  C2  information  such  as  orders  and  plans  to  be 
understandable  for  military  personnel,  for  simulated  forces,  and  for  future  robotic  forces.  In  addition,  BML  must 
provide  for  situational  awareness  and  a  shared,  common  operational  picture  through  digitized  reports.  BML  is 
particularly  relevant  in  a  network-centric  environment  for  enabling  mutual  understanding.  BML  also  must 
facilitate  C2SIM  interoperability  in  an  environment  where  multi-national  distributed  integrated  capabilities  are 
becoming  more  common  and  important. 

BML  is  independent  of  doctrine  but  provides  a  means  for  expressing  doctrine.  However  BML  is  not  intended  as 
a  means  to  standardize  doctrine:  the  vocabulary  must  be  well  defined  in  the  context  of  the  respective  application 
domain  to  unambiguously  generate  executable  tasks  at  the  end  of  the  process.  BML  must  model  these  aspects  in 
a  way  that  underlying  Information  Technology  systems  (M&S  or  C2  systems)  can  exchange  information  and 
also  can  properly  interpret  the  results.  Therefore,  the  Simulation  Interoperability  Standards  Organization  (SISO) 
undertook  the  development  of  standard  for  BML,  the  Coalition  Battle  Management  Language  (C-BML)  that 
uses  as  the  underlying  data  model,  the  JC3IEDM.  The  Joint  Consultation  Command  and  Control  Information 
Exchange  Data  Model  (JC3IEDM)  was  selected  since  it  represents  an  accepted  and  well-defined  set  of 
information  elements.  However  the  JC3IEDM  message  structure  is  not  part  of  the  C-BML  standard. 

Use-case  scenarios  involving  information  exchange  among  C2  systems  and  simulation  systems  often 
require  a  pre-requisite  initialization  of  all  systems  that  is  consistent  with  existing  operational  and/or  simulation 
databases.  This  has  represented  a  significant  obstacle  to  C2SIM  interoperation.  The  Military  Scenario  Definition 
Language  (MSDL),  which  has  been  employed  by  some  of  the  MSG-085  participating  Nations  as  a  standard 
along  with  C-BML  to  enable  C2SIM  interoperation,  has  been  developed  as  a  standard  by  SISO  for  the 
initialization  of  simulation  systems  with  scenario  data  using  a  common  format  [4]. 
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Interoperation  among  C2  and  simulation  systems  is  required  to  support  military  activities  such  as: 

•  Force  Readiness; 

•  Support  to  Operations;  and 

•  Capabilities  Development. 

Currently,  interoperating  systems  from  different  manufacturers  and/or  Nations  requires  proprietary  interfaces 
that  require  time  and  money  to  develop  and  maintain.  Furthermore,  in  many  cases,  in  addition  to  these  vendor- 
specific  interfaces,  human  intervention  is  required  during  military  scenario  definition,  initialization  and 
execution.  The  so-called  “swivel-chair”  interface  entails  feeding  simulation  operators  with  information  that  they 
must  translate  manually  into  instructions  that  the  simulations  can  process.  Replacing  such  operators  with  a 
standardized,  automated  interface  can  save  considerable  expense  and  at  the  same  time  result  in  a  more  robust  and 
timely  operations. 

Developing  standards  that  define  common  interfaces  for  the  exchange  of  military  information  among  C2  and 
simulation  systems  therefore  can  lead  to  significant  cost-reduction  and  greatly  facilitate  systems  integration. 
The  benefits  of  standardizing  C2SIM  interoperation  include: 

•  Reduced  cost  and  workload; 

•  Reduced  scenario  preparation  time;  and 

•  Increased  realism  and  overall  effectiveness. 

The  MSG-085  Mission  Statement  is  as  follows: 

Assess  the  operational  relevance  of  Coalition  Battle  Management  Language  (C-BML)  while 
contributing  to  C2SIM  standardization  and  assist  in  increasing  the  Technical  Readiness  Level  of 
C-BML  technology  to  a  level  consistent  with  operational  employment  by  stakeholders. 

Since  the  time  of  the  writing  of  the  MSG-085  Programme  Of  Work  (POW),  it  has  become  evident  that  C-BML 
alone  is  not  sufficient  to  meet  the  requirements  for  C2SIM  interoperation,  but  rather  should  be  utilized  in  concert 
with  other  standards  to  cover  other  aspects  of  C2SIM  federation  definition,  design,  development  and  execution. 


1.3  PREVIOUS  WORK  BY  NATO  ON  STANDARDIZATION  FOR  C2SIM 
INTEROPERATION 

The  Modelling  and  Simulation  Group  (MSG)  of  the  NATO  Coordination  Support  Office  (CSO)  has  supported 
several  technical  activities  related  to  C2SIM  interoperation  in  recent  years.  MSG-085  is  a  follow-up  activity 
to  the  MSG-048  technical  activity  that  was  conducted  from  2006  to  2010.  The  NATO  MSG-079  C-BML 
Workshop  was  held  in  February  2010,  prior  to  the  kick-off  of  MSG-085  in  June  2010. 

1.3.1  NATO  MSG-048 

The  findings  of  MSG-048  can  be  found  in  reference  [1].  In  addition  to  a  set  of  lessons  learned,  rich  in  experience 
from  the  MSG-048  experimentation  programme,  the  reference  [1]  also  provides  a  set  of  operational  and 
technical  requirements  for  C2SIM  interoperation  that  has  proven  useful  for  the  Simulation  Interoperability 
Standards  Organization  (SISO)  C-BML  standardisation  activities  as  well  as  informing  the  MSG-085  technical 
activity. 
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1.3.2  NATO  MSG-079 

The  MSG-079  Workshop  took  place  on  February  24-25th  2010  in  Famborough,  UK,  and  included  twenty-six 
presentations  proceeded  by  three  keynote  speakers.  Participation  included  approximately  sixty  attendees  with 
representation  from  twelve  Nations  [6].  Present  at  this  Workshop,  representatives  from  the  Multi-lateral 
Interoperability  Programme  (M1P)  Future  or  Block  4  Working  Group  suggested  that  the  C-BML  community 
consider  basing  the  C-BML  standard  on  the  MIP  capability  to  generate  “sub-views”  comprised  of  sub-sets  of 
M1P  data  elements,  relationships  and  business  rules. 


1.4  C2SIM  INTEROPERABILITY 

The  MSDL  and  C-BML  standards  have  been  developed  by  S1SO  to  support  scenario  initialisation  and  scenario 
execution,  respectively.  Initializing  and  executing  operational  scenarios  are  important  parts  of  several  military 
enterprise  activities  of  interest  to  the  MSG-085  Nations.  One  of  the  recommendations  from  the  MSG-048  final 
report  suggests  that  MSDL  and  C-BML  should  be  harmonized  as  a  pre-condition  to  establishing  a  combined 
C-BML/MSDL  standard  as  a  NATO  STANdardization  AGreement  (STANAG).  Toward  the  end  of  harmonizing 
the  standards,  S1SO  recently  has  merged  the  C-BML  and  MSDL  Product  Development  Groups  (PDGs)  to  form 
the  C2S1M  PDG.  However,  the  harmonized  standards  must  contribute  towards  achieving  the  benefits  of 
C2S1M  cited  above.  In  order  for  this  to  occur,  there  are  several  conditions  that  must  be  satisfied: 

•  MSDL  and  C-BML  must  be  mutually  consistent  and  usable  in  the  context  of  a  given  specific  military 
enterprise  activity; 

•  The  combined  MSDL/C-BML  standard  must  be  of  sufficient  technical  maturity  to  support  adoption  by 
stakeholders; 

•  It  must  be  easy  to  apply  changes,  when  required,  to  the  combined  MSDL/C-BML  standard  in  order  to 
support  timely  releases  of  new  revisions,  as  dictated  by  new  stakeholder  requirements; 

•  It  must  be  straightforward  to  apply  the  combined  MSDL/C-BML  for  the  design  and  development  of 
C2SIM  exercises  and  federations;  and 

•  Future  use  of  the  combined  MSDL/C-BML  standard  may  require  extensions  for  use  by  specific 
communities  and  therefore  it  should  be  possible  to  easily  extend  the  standard  to  meet  specific  C2SIM 
federation  requirements. 

Although  not  mentioned  in  the  original  POW,  over  the  course  of  the  MSG-085  Technical  Activity  it  has  become 
apparent  that  another  standard  also  can  be  a  useful  part  of  designing,  developing  and  executing  C2SIM 
federations.  This  is  the  SISO  Distributed  Simulation  Engineering  and  Execution  Process  (DSEEP).  MSDE  and 
C-BML  deal  mainly  with  information  exchange  whereas  the  DSEEP  addresses  the  process  for  designing  and 
building  a  distributed  simulation  environment.  The  addition  of  DSEEP  to  the  areas  of  interest  which  is  consistent 
with  one  of  the  main  lessons  learned  from  MSG-048  that  highlights  the  need  for  establishing  System  Design 
Agreements  (SDA)  as  part  of  a  Systems  Engineering  (SE)  approach  to  federation  development. 

1.4.1  Coalition  Battle  Management  Language  (C-BML) 

In  April  2014,  SISO  approved  the  initial  version  of  C-BML,  a  standardized  formal  language  for  the  exchange  of 
digitized  military  information  among  Command  and  Control  (C2),  simulation  and  autonomous  systems.  C-BML 
is  an  interoperability  standard  that  can  greatly  facilitate  the  preparation  and  execution  of  military  scenarios  in 
support  of  military  enterprise  activities  such  as: 
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•  Training; 

•  Support  to  Operations;  and 

•  Concept  Development  and  Experimentation. 

Preliminary  research  [8]  using  C-BML  already  has  shown  the  benefits  that  include: 

1 )  Reduced  exercise/ experiment  planning  and/or  preparation  time; 

2)  Increased  realism  of  the  training/experimentation  environment;  and 

3)  Decreased  cost  associated  with  the  decrease  in  the  number  of  required  simulator  operators. 

The  following  sections  describe  the  C-BML  standard  in  terms  of  language  components  and  the  corresponding 
standard  specifications. 


1.4. 1.1  Practical  Definition  of  C-BML 

C-BML  is  intended  to  be  an  unambiguous,  formal,  language  for  communicating  military  infonnation  for 
machine -to-machine  communication.  In  general  terms,  a  grammar  is  a  set  of  rules  that  dictate  what  valid 
sentences  or  expressions  (i.e.  combinations  of  lexical  elements)  can  be  constructed  for  a  given  language. 


Initiated  in  2006  with  the  formation  of  the  C-BML  PDG,  SISO’s  development  of  C-BML  has  proven  to  be  a 
difficult  task,  as  witnessed  by  the  time  required  to  produce  the  initial  balloted  Phase  1  specification  [5].  As  early 
as  1999,  Argo  et  al.  proposed  a  Battle  Management  Language  (BML)  suggesting  that  the  BML  expressions  be 
based  on  a  structure  that  included  5Ws  to  facilitate  the  programming  of  simulated/automated  units:  Who,  What, 
When,  Where  and  Why  [6].  The  5Ws  can  be  described  as  follows: 

•  Who:  The  tasking  unit;  The  tasked  unit;  The  supported  unit;  The  supporting  unit;  The  target; 

The  reporting  unit;  The  object  of  a  report. 

•  What:  The  type  of  operation  or  task  to  be  executed;  the  event  being  observed. 

•  Where:  Where  is  the  task  to  be  executed;  Where  is  the  event  being  observed? 


•  When: 


The  time  the  task  is  to  be  executed  or  has  been  executed;  the  time  an  event  is  observed. 


•  Why:  The  purpose,  motivation,  desired  effect  or  result. 


C-BML  has  followed  these  basic  definitions.  A  graphical  example  of  a  simple  C-BML  task  is  shown  in 
Figure  1-2.  The  Why,  which  adds  significant  complexity  has  not  been  included  for  clarity. 
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Figure  1-2:  Graphical  C-BML  Example  Illustrating  5Ws. 
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In  practice,  C-BML  expressions  will  be  communicated  using  one  of  several  concrete  syntaxes  such  as 
the  extensible  Markup  Language  (XML)  as  specified  in  the  C-BML  Phase  1  standard.  However,  other 
representations  like  the  Java  Serialized  Object  Notation  (JSON)  also  are  possible.  An  example  of  a  simplified 
XML  expression  for  an  Air  Interdiction  task  is  shown  in  Figure  1-3. 


c 

c 


<Order> 

<AirTask> 

cTaskee\Yho> 

<UmtID>CA-UAV<  UnitID> 

«Taskee\Mio> 

<WTiat> 

<ActionCode>AI<  ActionCode> 

<What> 

.  <\Miere> 

<WhereID>140 10000784 100000427c  \VhereID> 
<WhereLocation> 

<GDO 

<Lat>40. 062 1 95<  Lat> 
<Lon>47.57694<Lon> 
cElevAGL>3000.0cElevAGL> 
<GDO 

<  WhereLocation> 

^  cTYhere> 

CcS  t  a  rt  \Yh  en  Tune> 

<StartTimeQualifier>AT<  StartTimeQualifier> 
<DateTime>2009 1022141229. 3 59<  DateTime> 
c  StartWhenTime> 

<Affected\Mio> 

<UmtID>OMF  1 9  5-B 1 2c  UnitID> 

<  Affected\Yho> 

<TaskID>  140999990000000000 1 9<  TaskID> 

c  AirTask> 

<OrderIssuedTime>2009 1022 14 1443.000c  OrderIssuedTime> 
cOrderID>  1 4099999000000000030c  OrderID> 

CcTasker\Mio> 

cUnitID>  1  -HBCTc  UnitID> 

cTasker\3ho> 
c  Orders 


c 


Figure  1-3:  Simplified  C-BML  XML  Example. 


1.4. 1.2  SISO  C-BML  Product  Development  Plan 

C-BML  is  of  the  family  of  Battle  Management  Languages  (BML)  and  like  other  languages  is  comprised  of: 
vocabulary,  grammar and  semantics.  The  vocabulary  and  grammar  are  required  to  construct  valid,  syntactically 
correct  expressions  representing  military  information.  However,  additional  information,  such  as  doctrine, 
is  required  to  correctly  interpret  the  intended  meaning  of  this  information,  which  may  differ  across  services, 
Nations  or  depending  on  the  nature  of  the  operation.  In  addition  to  the  vocabulary  and  grammar  components  of 


1  Fomially,  grammars  always  include  vocabularies,  but  this  distinction  was  made  in  the  interest  of  defining  a  standard  product 
development  plan. 
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the  C-BML  standard,  the  SISO  C-BML  PDG  also  has  identified  the  need  for  a  C-BML  ontology  to  capture  and 
to  represent  such  additional  information. 

In  2006,  the  SISO  C-BML  Study  Group  produced  a  report  [7]  with  the  following  recommendation: 

“[...]  For  all  versions,  the  Study  Group  recommends  using  the  [Command  and  Control  Information 
Exchange  Data  Model]  C2IEDM  and  its  successor  (Joint  Consultation  Command  and  Control 
Information  Exchange  Data  Model  —  JC3IEDM)  as  a  basis  for  C-BML  reference  implementations  and 
standards.  [...]” 

Reference  [7]  further  recommends  that  the  first  version  of  C-BML  be  described  as  a  data  model  (i.e.  base 
vocabulary)  defined  in  XML  as  a  sub-set  of  the  C21EDM.  However  it  was  recognized  that  there  might  be  a  need 
for  extensions  to  meet  requirements  from  the  Modelling  and  Simulation  (M&S)  community.  It  also  was 
recommended  that  the  second  version  of  C-BML  introduce  the  C-BML  grammar,  while  the  third  version  would 
address  the  need  for  ontology-based  solutions. 

Therefore,  the  SISO  C-BML  Product  Development  Group  has  established  a  three-phase  plan  for  developing 
C-BML  as  follows: 

Phase  1 :  Establish  a  vocabulary  or  basic  lexicon  composed  primarily  of  terminal  symbols; 

Phase  2:  Define  a  grammar  or  set  of  production  rules  that  indicates  how  to  combine  the  vocabulary  to  form 
valid  expressions;  and 

Phase  3:  Introduce  an  ontology  or  set  of  relationships  that  can  facilitate  the  interpretation  of  C-BML 
expressions. 

In  reality,  the  plan  allows  for  overlap  of  the  phases,  as  shown  in  Figure  1-4  wherein  Phase  1  also  includes 
preliminary  grammar,  and  Phase  2  includes  preliminary  ontology  work. 
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Figure  1-4:  SISO  C-BML  Overview. 
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The  C-BML  Phase  1  development  activity  recently  has  been  completed,  resulting  in  an  approved  standard. 
The  C-BML  Phase  1  product  is  consistent  with  the  recommendation  to  use  the  JC31EDM  [7]  as  the  underlying 
data  model  to  define  the  C-BML  vocabulary.  The  new  C2S1M  PDG  has  assumed  responsibility  for  the  Phase  2 
development  activity  that  seeks  to  build  upon  the  vocabulary  defined  in  Phase  1  and  complement  this  with 
formal  grammar  definition  and  basic  ontology. 

Since  the  SISO  C-BML  and  MSDL  Product  Development  Groups  recently  voted  to  merge  the  two  groups  into 
one  “C2S1M”  group  that  would  oversee  development  of  a  unified  second  version/phase  of  the  two  standards. 
The  successor  to  C-BML  Phase  2  might  take  a  somewhat  different  path,  although  it  is  reasonable  to  assume  that 
it  will  seek  to  provide  continuity  with  C-BML  Phase  1 . 

Figure  1-4  also  illustrates  additional  elements  of  the  Message  Framework  as  part  of  the  proposed  C-BML 
Standard  Development  Framework  (SDF)  [8],  such  as  the  C-BML  message  structure  and  the  distinction  between 
production  rules  (i.e.  grammar)  and  business  rules  (i.e.  domain-specific  or  additional  logic  that  is  not  specified  as 
part  of  the  grammar). 

Figure  1-5  illustrates  the  re-use  of  the  JC31EDM  codes  and  simple  types  (shown  in  the  green  layer)  represented 
using  dashed  lines.  In  this  figure,  C-BML  elements  are  represented  as:  codes,  entity-types,  complex-types 
(e.g.  action-types,  facility-types,  person-types  etc.),  and  composites.  The  composites  include  definitions  for 
elements  that  represent  the  5Ws,  discussed  in  the  previous  sections.  Following  a  successful  balloting  process  in 
September  2012,  the  C-BML  Phase  1  product  became  an  official  standard  in  April  2014. 


C-BML  namespace: 

http://www.sisostds.org/schemas/c-bm  1/1.0 
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Figure  1-5:  SISO  C-BML  Phase  1  Schema  Structure. 
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1.4.1.3  C-BML  Vocabulary  and  Grammar  Considerations 

A  formal  grammar  is  a  set  of  mathematical  rules  that  can  be  used  by  processing  elements  called  lexers  and 
parsers  for  processing  language  expressions.  In  general  terms,  a  language  L,  is  the  set  of  all  expressions 
(or  sentences)  that  can  be  formed.  It  can  be  generated  from  a  formal  grammar  G,  and  therefore  can  be  expressed 

as  L  (G) . 

A  grammar  can  be  defined  by  a  set  of  production  rules  P  that  operate  on  a  set  E  of  elements  referred  to  as 
symbols.  E  is  comprised  of  two  sets  of  symbols:  the  set  of  non-terminal  symbols  N,  and  the  set  of  terminal 
symbols  T .  Non-terminal  symbols  can  be  expanded  to  clauses  and  other  constituents.  These  symbols  are  not 
the  expressions  or  phrases;  they  are  symbols  for  a  generalization  of  these  expressions  or  phrases. 

Terminal  symbols  are  elementary  symbols  that  cannot  be  broken  down  further  and  for  the  intents  and  purposes 
of  C-BML  they  can  be  considered  to  form  the  C-BML  vocabulary  and  may  include  keywords,  identifiers,  codes 
and  values  of  core  data  types.  Non-terminal  symbols  are  clauses,  phrases  and  expressions  of  which  a  sub-set  is 
the  so-called  set  of  start  symbols,  a.  Non-terminal  symbols  are  used,  for  example,  to  represent  entities  such  as 
units,  control-features  or  properties  such  as  temporal-validity  and  location.  Start  symbols  indicate  the  roots  of 
valid  complete  expressions  or  sentences  (e.g.  report,  order,  request,  ackno wledgement).  Hence,  formal 
grammars  can  be  expressed  as  quadruples: 

G  =  (T,  N,  a,  P) 

Formal  grammars  can  be  represented  as  trees,  or  more  specifically,  Abstract  Syntax  Trees  (AST),  where  the 
leaves  are  terminal  symbols  and  branching  points  are  non-terminal  symbols.  In  order  to  process  formal  language 
expressions  using  software  components,  AST  are  transformed  into  Concrete  Syntax  Trees  (CST)  that  also  are 
known  as  parse  trees  used  by  parsers. 

Examples  of  BML  grammars  are  the  Command  and  Control  Lexical  Grammar  (C2LG)  [11]  and  the  Operations 
Intent  and  Effects  Grammar  (OlEG)  [12].  Both  of  these  grammars  borrow  from  Lexical  Functional  Grammar 
(LFG)  framework  that  has  the  benefit  of  being  well-adapted  for  analyzing  and  generating  natural  languages. 
How  well  the  LFG  approach  will  satisfy  user  needs  for  specifying  C-BML  will  be  determined  as  the  S1SO 
C2S1M  activity  goes  forward.  Some  users  have  expressed  the  desire  for  a  “simple”  grammar  that,  if  necessary, 
references  an  ontology  that  provides  information  required  for  interpretation.  One  perspective  is  that  the  language 
should  not  impose  too  many  restrictions  on  what  constitutes  a  meaningful  expression,  but  rather  only  to  specify 
what  constitutes  a  syntactically  and  structurally  complete  and  correct  expression.  One  way  to  do  this  is  for  the 
semantics  to  be  represented  as  an  ontology  rather  than  being  shaped  by  the  grammar. 

1.4.1.4  C-BML  Ontology 

As  described  above,  a  formal  language  can  be  defined  by  a  grammar  as  the  set  of  valid  expressions  or  sentences 
that  are  syntactically  correct  -  but  in  order  to  interpret  these  expressions,  additional  semantics  may  be  required. 
In  some  cases,  an  ontology  may  not  be  needed  by  C-BML  consuming  applications.  However,  for  applications 
that  utilize  inference  or  reasoning  engines,  additional  information  may  be  required  to  properly  process  C-BML 
encoded  information.  Ontological  means  can  be  used  to  relate  elements  of  formal  language  expressions  and  state 
facts  and  assertions  that  are  difficult  or  verbose  to  express  using  traditional  formal  grammars. 

Therefore,  the  C-BML  ontology  complements  the  grammar  by  adding  additional  relationships  and  constraints 
among  data  elements.  Ontologies  also  allow  for  specifying  information  about  data  instances  as  well.  Hence, 
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ontologies  may  be  used  during  application  development  to  ensure  the  proper  utilization  of  the  C-BML  language 
by  applications  or  may  be  used  during  application  run-time  to  construct  a  knowledge  repository  to  store  and 
derive  new  information. 

The  C-BML  ontology  would  define  a  set  of  universal  relationships  or  semantics  that  are  common  to  all  C-BML 
producer  and  consumer  applications  (e.g.  a  taxonomy  of  control  features).  However,  it  is  unlikely  that  a  single 
ontology  will  meet  all  of  the  service-specific  or  community-specific  needs  and  therefore  ontology  extensions 
will  be  required.  Hence,  the  C-BML  ontology  could  be  included  in  the  standard  as  a  core  ontology  based  on 
NATO  doctrine  and  procedures,  while  allowing  for  specific  communities  of  interest  to  extend  the  ontology  to 
meet  their  needs. 

MSG-085  work  on  ontology  calls  for  the  use  of  the  Unified  Modelling  Language  (UML)  from  the  Object 
Management  Group  (OMG)  as  the  central  modelling  language.  Therefore  it  is  of  interest  to  consider  how  one 
may  represent  ontologies  using  UML.  UML  can  be  used  to  represent  conceptual  models,  sometimes  referred  to 
as  Platform  Independent  Models  (P1M)  in  the  Model-Driven  Architecture  (MDA)  terminology.  However,  UML 
alone  does  not  lend  itself  to  specifying  model  constraints  and  for  this  reason  the  OMG  has  developed  the 
complementary  Object  Constraint  Language  (OCL)  that  provides  a  formal  expression  of  rules  such  as  invariants. 
Although  ontologies  also  can  be  considered  as  conceptual  models,  UML  and  OCL  are  not  well-suited  to  specify 
ontologies  since  many  of  the  ontology  constructs  are  lacking.  The  Web  Ontology  Language  (OWL)  that  has 
been  developed  for  this  purpose  is  better  suited  to  represent  certain  aspects  of  conceptual  model,  in  particular  the 
specification  of  restrictions.  The  OMG  has  recognized  the  usefulness  of  ontologies  and  of  the  OWL 
specification  and  has  created  a  UML  profile  called  the  Ontology  Definition  Metamodel  (ODM)  that  allows  for 
the  representation  of  an  OWL  ontology  in  UML.  References  [10],  [21],  [22]  advocate  an  approach  wherein  an 
ontology  is  produced  in  the  form  of  a  set  of  OWL  modules  that  are  generated  from  an  UML  ODM  ontology 
constructed  following  a  well-defined  process  and  using  a  dedicated  toolset.  The  requirements  for  the  C2S1M 
ontology  are  still  being  collected;  consequently  this  work  is  still  of  an  exploratory  nature. 

1.4.1. 5  C-BML  Development  Process  and  Tools  -  From  Phase  1  to  Phase  2 

The  C-BML  Phase  1  development  activity  did  not  employ  a  formal  process  and  dedicated  tools  for  elaborating 
the  main  product  artefact,  the  C-BML  schema,  illustrated  in  Figure  1-5.  The  schema  was  handcrafted  directly 
using  XML  editor  tools  and  therefore  although  an  implicit  model  can  be  associated  with  an  XML  schema, 
no  corresponding  logical  data  model  or  conceptual  model  was  constructed  as  the  basis  for  the  schema. 
This  approach  has  been  the  source  of  many  difficulties,  perhaps  the  most  important  of  which  is  an  inherent 
difficulty  in  applying  changes  to  the  existing  C-BML  Phase  1  product.  This  makes  it  difficult  to  maintain  or 
evolve  the  Phase  1  products.  Also,  no  formal  requirements  have  been  gathered  or  managed  for  Phase  1. 
Thus  many  questions  subsist:  What  requirements  have  been  satisfied  by  specific  schema  elements?  What  were 
the  reasons  behind  a  specific  modelling  strategy??  What  changes  need  to  be  applied  in  order  to  maintain 
consistency  with  the  underlying  JC3IEDM  vocabulaiy?  Lessons  learned  from  C-BML  Phase  1  drafting 
activity  have  been  inputs  into  the  proposed  C-BML  SDF  that  highlights  the  need  for  a  Logical  Data  Model 
representation  and  the  ability  to  generate  more  than  one  concrete  syntax  or  physical  model.  The  agility  that 
results  from  this  approach  is  consistent  with  the  process  and  tools  developed  by  the  M1P  for  the  purposes  of 
building  and  maintaining  C2  interoperability  solutions  (see  Chapter  4). 

The  C-BML  Phase  2  Development  Activity  already  has  been  initiated  and  has  identified  several  areas  that  need 
to  be  addressed,  including: 

1 )  Establishing  a  set  of  stakeholder  requirements; 

2)  Defining  a  normalized,  logical  data  model  (i.e.  P1M);  and 
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3)  Creating  a  mechanism  for  the  automatic  generation  of  physical  model  or  Platform-Specific-Model 
(PSM),  including  XML  Schema  Description  (XSD)  documents  and  possibly  preliminary  OWL  ontology 
modules. 

Reference  [21]  describes  how  the  use  of  the  M1P  Block  4  model  and  tools  will  help  to  achieve  the  Phase  2 
objectives  in  the  form  of  a  well-defined,  well-documented,  sustainable  process  and  tool  chain. 

1.4.2  Military  Scenario  Definition  Language  (MSDL) 

The  Military  Scenario  Definition  Language  [5]  is  intended  to  reduce  scenario  development  time  and  cost  by 
enabling  creation  of  a  separable  simulation  independent  military  scenario  format,  focusing  on  real-world  military 
scenario  aspects,  using  the  industry  standard  data  model  definition  XML  that  can  easily  and  dependably  be 
consumed  by  current  and  evolving  simulations.  The  initial  MSDL  capability  was  prototyped  within  OneSAF 
during  its  early  architectural  development  phase  between  2001  and  2004.  A  S1SO  Study  Group  (SG)  concluded 
that  there  was  a  community-wide  need  for  a  standardized  military  scenario  format  to  reduce  development  time 
and  cost,  and  to  enable  sharing  of  valuable  scenario  products.  The  standardized  scenario  format  also  provides  a 
way  to  automate  the  largely  manual  reproduction  of  a  scenario  into  multiple  simulation  scenario  formats  and 
reduce  the  number  of  errors  introduced  during  this  manual  process. 

In  2006,  a  formal  S1SO  MSDL  standard  Product  Development  Group  (PDG)  was  established  with  the  specific 
intent  of  producing  a  standard  Military  Scenario  Definition  Language  data  model.  The  PDG  reviewed  previous 
OneSAF  work,  expanded  and  aligned  it  with  the  JC31EDM.  Development  included  adding  some  elements  such 
as  weather  information,  and  a  scenario  identification  section  leveraging  the  Base  Object  Model  Identification 
schema  and  removing  elements  that  were  under  study  or  standards  development  such  as  the  Course  of  Action 
structure  that  was  equivalent  to  the  work  being  pursued  under  the  SISO  C-BML  PDG.  Version  1.0  of  the 
resulting  SISO  standard  was  approved  in  November  2008.  Beyond  OneSAF,  MSDL  has  been  employed  by  the 
US  Army  Modeling  and  Simulation  Office  (AMSO),  Air  Force,  and  Marine  Coips  as  well  as  NATO  activities 
including  Spain,  France,  the  United  Kingdom,  Norway,  Germany,  Canada,  and  others. 

1.4.3  Distributed  Simulation  Engineering  and  Execution  Process  (DSEEP) 

The  DSEEP  deals  with  engineering  and  executing  (distributed)  ‘simulation  environments’,  where  ‘simulation 
environment’  is  a  generic  term  that  includes  Live,  Virtual  and  Constructive  (LVC)  simulations  including  all  Live 
assets  which  are  connected  together  with  a  common  Simulation  Data  Exchange  Model  (SDEM)  under  a  set  of 
common  agreements.  The  assets  that  are  connected  are  called  member  applications.  An  environment  where  the 
member  applications  are  simulation  and  C2  systems  is  a  simulation  environment  that  falls  under  the  definition  of 
the  DSEEP.  This  means  that  a  C2S1M  federation  can  be  defined  as  a  simulation  environment  that  contains  at 
least  one  C2  system,  and  that  uses  a  C2S1M  data  exchange  model  as  the  SDEM.  Not  only  the  SDEM  is  of 
importance,  also  the  agreements  need  to  be  taken  into  account.  This  has  led  to  the  idea  that  when  using  C-BML 
and  MSDL  the  terminology  and  engineering  steps  to  be  taken  should  be  aligned  with  those  in  DSEEP. 

While  the  MSDL  and  C-BML  standards  go  a  long  way  to  provide  standards-based  data  exchanges  between 
coalition  systems,  both  data  models  allow  flexibility  along  too  many  dimensions  to  have  confidence  that 
exchanges  between  MSDL/C-BML  compliant  systems  will  work  without  additional  alignment.  For  example 
MSDL  allows  geographic  coordinates  to  be  specified  in  geocentric  (x,  y,  z)  or  geodetic  (latitude,  longitude) 
coordinates.  To  ensure  system-to-system  understanding  of  locations,  MSG-085  participants  agreed  to  exchange 
geodetic  coordinates.  Similar  agreements  are  necessary  to  ensure  understanding  of  even  simple  C-BML  based 
orders  such  as  movement  orders  that  could  potentially  include  movement  routing  information  constructed  from  a 
variety  of  waypoint-based,  referencing  based,  or  start  and  end-point  based  data  elements. 
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2.1  BACKGROUND 

The  MSG-085  Technical  Activity  (TA)  builds  upon  the  work  done  in  MSG-048.  The  focus  of  MSG-048  was  on 
evaluating  and  demonstrating  the  technical  feasibility  of  a  C-BML-enabled  approach  to  C2S1M  interoperation. 
The  MSG-085  TA  addressed  the  problem  areas  and  obstacles  highlighted  in  MSG-048  and  provide  guidance 
and  input  to  in  support  of  the  finalization  of  the  C-BML  standard  and  its  alignment  with  MSDL.  In  addition, 
MSG-085  sought  to  ensure  that  the  standards  support  the  operational  use-cases  as  collected  from  the  Nations  and 
NATO  stakeholders  and  thus  allow  for  C2S1M  interoperation  while  providing  feedback  to  the  community  for 
initiatives  that  will  ultimately  result  in  an  increase  in  the  Technical  Readiness  Level  (TRL)  of  C-BML -related 
technologies  to  a  level  consistent  with  operational  employment. 

Although  the  final  goal  of  the  MSG-085  TA  does  not  lie  solely  in  the  adoption  of  a  single  standard  or 
technology,  the  participating  Nations  have  identified  C-BML  and  MSDL  as  the  key  enabling  technologies  for 
C2S1M  interoperation. 


2.2  OBJECTIVES 

The  MSG-085  high-level  objectives  described  below  are  represented  graphically  in  Figure  2-1,  taken  from  the 
MSG-085  POW  [2],  The  principal  high-level  objectives  of  the  MSG-085  are  as  follows: 

•  Define  the  scope  and  operational  and  technical  requirements  for  C-BML; 

•  Establish  a  set  of  reference  expressions  based  on  NATO  operational  procedures; 

•  Assess  and  leverage  available  C-BML  implementations; 

•  Address  C2  systems  and  Simulation  Initialization  Requirements;  and 

•  Demonstrate  and  communicate  the  operational  relevance  and  benefits  of  C-BML  for  improving  the 
efficiency  of  military  operations. 


Based  on  NATO  Procedures 
Operational  Concept  Desc. 
Operational  Use-cases 
Experimentation 


■  Recommendations  for 
Standardization 
’  Technical  Requirements 
1  Experimentation  Support 


’’I 


Technical 

Correctness 


•  End-user  Involvement 

•  Experimentation  with  Stakeholders 

•  Validation  on  use  of  MIP  Products 


Figure  2-1:  MSG-085  Technical  Activity  Objectives. 
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2.3  ACTIVITIES 

In  order  to  achieve  these  objectives,  the  following  activities  were  defined  and  executed  by  the  group: 

•  Requirements  analysis; 

•  Establishing  recommendations  for  development  and  the  use  of  C2S1M  interoperability  standards; 

•  Demonstrations,  experimentation  and  evaluation;  and 

•  Organization  of  communication  events. 

Figure  2-2  provides  an  overview  of  the  major  activities,  events  and  outputs  as  a  function  of  a  3-phase 
programme  of  work  described.  In  2012,  a  one -year  extension  was  requested  of  the  NATO  Collaboration  Support 
Office.  This  extension  allowed  for  additional  communication  and  experimentation  events  and  also  for  the 
redaction  of  the  final  report. 
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Figure  2-2:  MSG-085  Activities  and  Events  Overview. 


2.3.1  Requirements  Analysis 

During  the  second  phase  of  the  technical  activity,  requirements  analysis  activities  included  the  elaboration  of  a 
set  of  operational  requirements  and  associated  technical  requirements.  The  MSDL  and  C-BML  standards  are 
technical  in  nature,  but  must  be  grounded  with  an  operational  context.  The  operational  requirements  analysis 
activity  involved  defining  a  set  of  operational  use-cases  and  the  elaboration  of  Operational  Concept  Description 
(OCD)  documents  for  mission  planning  [13]  and  for  Command  Post  training  [14].  The  technical  requirements 
activity  linked  the  operational  requirements  produced  by  the  Technical  Group’s  operational  Subject-Matter 
Experts  (SME)  to  technical  requirements  that  were  derived  by  a  dedicated  group  that  produced  a  draft  technical 
requirements  specification  [9]. 
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2.3.2  Lessons  Learned  and  Recommendations 

One  of  the  main  objectives  of  MSG-085  was  to  provide  guidance  and  recommendations  to  the  C-BML 
community  concerning  requirements  for  standardization  and  for  future  use  of  C2SIM  interoperability  standards. 
These  recommendations  were  to  include: 

•  Guidance  concerning  the  use  of  the  M1P  products; 

•  Recommendations  for  developing  the  C2S1M  interoperability  standards;  and 

•  Guidance  for  using  the  C2S1M  interoperability  standards  and  technologies  based  on  the  Technical 
Group’s  collective  experience  and  lessons  learned. 

As  specified  in  the  Programme  of  Work,  the  MSG-085  Technical  Group  informed  the  C2S1M  community  of  the 
lessons  learned,  recommendations  and  other  findings  by  organizing  demonstrations,  symposia  and  workshops 
for  which  the  group  gave  live  demonstrations,  presentations  and  submitted  papers.  The  MSG-085  Technical 
Group  also  participated  in  several  international  workshops  and  symposia  where  the  group’s  findings  have  been 
documented.  The  MSG-085  participation  in  communication  events  also  served  to  solicit  feedback  from 
the  larger  community  of  C2S1M  stakeholders  and  is  described  in  Chapter  5.  The  lessons  learned  and 
recommendations  are  summarized  in  Chapters  6  and  7,  respectively. 

2.3.3  Demonstrations,  Experimentation  and  Evaluation 

The  initial  MSG-085  Experimentation  Programme  planned  for  a  number  of  experimentation  events  including: 

1)  Traditional  experiments  (e.g.  hypotheses-based);  and 

2)  Demonstrations. 

Due  to  time  and  resource  constraints,  primarily  demonstrations  were  held  during  international  conferences  and 
trade  shows  such  as  I/ITSEC 1  (in  North  America)  and  1TEC2  (in  Europe). 

These  demonstrations  illustrated  capabilities  that  were  developed,  tested  and  assessed  over  the  course  of  the 
MSG-085  lifetime  and  the  preparation  for  these  events  required  the  resolution  of  technical  issues  that  generated 
many  lessons  learned. 

The  final  demonstration  built  upon  the  capabilities  developed  during  the  previous  demonstrations  and  included 
an  in-depth  evaluation  from  operational  SME. 

2.3.4  Communication  Events,  Workshops  and  Symposia 

In  parallel  with  the  experimentation  events  and  consistent  with  Figure  2-2,  MSG-085  also  organized  a  number 
of  communication  and  education  events  to  share  the  results  and  findings  of  the  group  with  community  of 
stakeholders.  These  events  included  dedicated  sessions  and/or  symposia  held  during  the  two  S1SO  Interoperability 
Workshops  (SIW)  and  the  International  Command  and  Control  Research  and  Technology  Symposium  (ICCRTS) 
as  well  as  two  NATO  MSG  Workshops.  The  demonstrations  that  were  held  also  contributed  to  communicating 
the  results  and  findings  of  the  group. 


1  Interservice/Industry  Training,  Simulation  and  Education  Conference  (I/ITSEC). 

2 

International  Training  and  Education  Conference  (ITEC). 
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2.4  MSG-085  ORGANISATION 

The  MSG-085  Technical  Activity  included  participation  from  thirteen  Nations,  which  led  to  a  programme  of 
work  with  a  significant  number  of  activities  and  deliverables,  as  shown  above.  An  organisational  structure, 
shown  in  Figure  2-3,  was  put  in  place  to  organize  these  activities  and  was  formed  of  three  groups: 

1)  The  Management  Sub-Group  formed  by  the  MSG-085  National  Leads  and  the  MSG-085  Secretary; 

2)  The  Operational  Sub-Group  (OSG);  and 

3)  The  Technical  Sub-Group  (TSG). 
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Figure  2-3:  MSG-085  Organisation. 


The  TSG  also  included  liaisons  to  the  M1P  and  S1SO  organizations;  these  are  the  main  technical  stakeholders’ 
organizations  for  the  MSG-085  activities. 


2.5  COMMON  INTEREST  GROUP  (CIG)  APPROACH 

The  MSG-085  Technical  Activity  included  participation  from  13  Nations.  Meetings  were  held  at  a  pace  of 
four  times  per  year  with  additional  participation  from  a  smaller  group  of  Nations  at  the  I/ITSEC  and  1TEC 
conferences.  Meeting  attendance  generally  ranged  from  30  -  40  participants.  National  representation  and 
interests  varied  greatly  from  Nation  to  Nation  and  covered  the  Air,  Land,  Maritime  and  Joint/Combined 
domains.  For  this  reason,  early  in  2012,  it  was  decided  to  form  a  series  of  Common  Interest  Groups  (CIG)  that 
could  explore  specific  themes  or  topics  in  accordance  with  national  interests.  Each  CIG  developed  a  work  plan 
consistent  with  and  traceable  to  the  MSG-085  POW  activities  and  deliverables. 
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2.5.1  Common  Interest  Group  Organisation 

The  formation  of  the  CIG  was  not  intended  to  replace  the  existing  organizational  structure  as  described  in  the 
MSG-085  POW  [3],  but  rather  to  complement  the  OSG  and  TSG  activities  through  focused  efforts  on  specific 
military  domain  enterprise  activities  where  C2S1M  interoperability  issues  needed  to  be  addressed. 

Figure  2-4  depicts  the  overall  CIG  approach  wherein  specific  CIG  comprise  both  technical  and  operational 
SMEs  from  the  TSG  and  OSG,  respectively.  Each  CIG  performs  activities  in  its  dedicated  focus  area  and  then 
reports  back  to  the  TSG  and  OSG  on  a  regular  basis. 


CIG  1 
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includes  OSG  and 
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Figure  2-4:  Common  Interest  Group  Approach. 

CIGs  were  encouraged  to  hold  regular  meetings  outside  of  the  MSG-085  general  meetings  and  also  to  hold 
individual  and  combined  demonstrations  and  other  experimentation  events.  Some  CIGs  did  not  perform 
experimentation  events  but  rather  focused  on  analysis  and  producing  documents. 

2.5.2  MSG-085  Common  Interest  Groups 

In  February  2012,  Common  Interest  Groups  were  formed  (see  Figure  2-5)  for  the  following  focus  areas: 

•  Autonomous  Air  Operations  (AAO); 

•  Land  Operations; 

•  Maritime  Operations; 

•  Joint  Mission  Planning; 

•  Technical  MSDL/C-BML  Messaging  Infrastructure;  and 

•  Requirements  Recommendations  and  Specifications  (2RS),  (added  in  February  2013). 
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Figure  2-5:  MSG-085  Common  Interest  Groups. 

Figure  2-5  indicates  the  participation  by  the  Nations  in  the  different  CIGs.  The  outputs  from  the  CIGs  were 
provided  to  the  OSG  and  TSG  as  contributions  to  the  MSG-085  deliverables  as  specified  in  the  POW. 
In  November  2012,  a  C1G  Workshop  was  held  during  which  demonstrations  and  briefings  were  made 
(see  Section  5.6). 

2.5.2. 1  MSG-085  Autonomous  Air  Operations  (AAO)  CIG 

The  focus  of  MSG-085  was  on  standardization  for  C2S1M  interoperation.  However,  technologies  such  as  the 
Coalition  Battle  Management  Language  (C-BML)  also  provide  for  interoperability  among  C2  systems, 
simulations  and  autonomous  systems.  As  stated  in  the  POW,  the  requirements  for  communication  between  C2 
and  autonomous  systems  are  in  many  aspects  similar  to  those  for  communication  between  C2  and  simulation 
systems. 

The  focus  of  the  AAO  CIG  was  on  Concept  Development  and  Experimentation  (CD&E)  using  a  distributed 
simulation-based  experimentation  environment.  In  particular,  the  air  domain  provided  the  context  for  exploring 
new  concepts  and  approaches  for  capabilities  that  include  autonomous  systems  employment  within  C4ISTAR3 
architectures.  These  architectures  will  leverage  net-enabled  services  in  order  to  achieve  automated  information 
exchanges  in  support  of  new  capabilities. 

The  AAO  CIG  objectives  are  as  follows: 

•  Elaborate  a  set  of  services  that  support  automated  information  flows  for  the  purposes  of  developing  new 
C4ISR/C4ISTAR  architectures,  and  exploring  relevant  autonomous  air  operations  concepts  within  this 
context; 


3 

Command,  Control,  Communications,  Computers,  Information/Intelligence,  Surveillance,  Targeting  Acquisition  and  Reconnaissance. 
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•  Extend  and  refine  the  current  C-BML  standard  to  include  requirements  for  air  operations  information 
exchange  and  in  support  of  the  net-enabled  services  approach;  and 

•  Demonstrate  and  compare  the  use  of  different  C-BML  messaging  infrastructures. 

Lead  Nation:  Canada. 

Participating  Nations:  Great  Britain,  United  States. 


2.52.2  MSG-085  Land  Operations  CIG 

The  CIG  Land  Operations  aims  were  to  specify,  develop  and  demonstrate  improved  C-BML  capabilities  for 
land-focused  training  and  planning  purposes.  Hence,  the  CIG  works  focused  on  the  following  objectives: 

•  Enhancing  land  manoeuvre  logistics  features  (sustainment  of  fuel  and  personnel  in  addition  to 
ammunition  consumption  and  status  of  devices); 

•  Defining  request/order/report  for  artillery  support; 

•  Extending  the  list  of  tasks  that  C-BML  is  able  to  support  to  address  stabilization  phase  of  operations; 

•  Providing  for  exchange  of  information  between  simulations  and  legacy  C2  systems  according  to 
operational  interfaces  and  flow  of  information;  and 

•  Defining  a  consistent  operational  initialization  process  between  coalition  C2  and  simulation  systems. 

In  order  to  achieve  these  goals,  a  new,  non-parsing  BML  server  developed  by  LK1E4  was  used.  The  MSDL 
schema  was  enhanced  in  order  to  define  unit  types  consistent  with  JC3IEDM  dictionaries,  to  use  NATO  APP-6 
standard  symbols  (for  units,  boundaries,  etc.)  and  for  the  logistic  domain  to  initialize  holdings  of  units  by  using 
the  NSN  (NATO  Stock  Number)  codes. 


In  addition,  a  new  CBML  message  structure  was  also  developed  so  that  exchanges  between  systems  were 
consistent  with  the  real  operational  flow  of  information.  Several  new  CBML  expressions  were  added,  such  as: 

•  Operational  message  ‘Roger’  /  ‘Apercu’:  Acknowledgement  message  reporting  the  status  of  an  order 
and  in  case  of  failure  the  reasons  why; 

•  Call  for  fire  (Neutralize,  Destruction,  Illuminate,  Obscure):  Request  for  support  (artillery  fire)  used 
either  from  a  simulated  unit  to  a  C2  system,  or  from  a  C2  system  to  a  simulated  supporting  unit; 

•  Start  firing  /  Suspend  firing:  Task  command  to  start  or  resume,  suspend  or  cancel  a  request  for  support; 
and 

•  firing  reports:  Provide  status  (In  progress,  Completed,  Cancelled,  etc.)  of  a  requested  task. 


These  improvements  were  demonstrated  in  December  2012  during  a  demonstration  event  at  GMU  and  I/ITSEC 
based  on  an  operational  scenario  reused  from  the  Viking  2011  exercise.  The  C2  systems  SICL,  SIR,  SIT  AW  ARE, 
TALOS  and  C2LG  and  simulations  SWORD  and  VR-Forces  were  provided  by  participating  Nations. 

Lead  Nation:  France. 


Participating  Nations:  Denmark,  Germany,  Netherlands,  Spain. 


4  Fraunhofer  Institute  for  Communication,  Information  Processing  and  Ergonomics  (FKIE). 
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2.5.2.3  MSG-085  Maritime  Operations  CIG 

While  there  have  been  numerous  publications  on  the  use  of  BML  for  the  land  domain  and  the  air  domain, 
few  public  results  are  available  on  the  application  of  BML  to  maritime  operations.  The  maritime  CIG  evaluated 
the  applicability  of  the  S1SO  C-BML  Draft  Specification  to  capture  orders  that  cover  selected  parts  of  the 
maritime  surface  warfare  domain,  and  to  identify  necessary  extensions.  More  specifically,  the  CIG  analysed 
relevant  parts  of  the  Operational  General  Matter  (OPGEN),  Operational  Tasking  Anti-Surface  Warfare 
(OPTASK  ASUW)  and  Operational  Tasking  Amphibious  (OPTASK  AMPH1B). 

Example  OPGEN  and  OPTASK  ASUW  orders  were  developed  based  on  the  Viking  2011  Bogaland  Scenario. 
The  corresponding  formatted  message  templates  [18]  were  analysed  in  order  to  extract  Information  Exchange 
Requirements  relevant  to  interpretation  of  orders  by  a  computer.  The  Information  Exchange  Requirements, 
captured  in  form  of  a  System/Sub-system  Specification  (SSS),  were  input  to  the  MSG-085  C2-Sim  Initialization 
Requirements.  The  example  orders  were  mapped  to  the  SISO  C-BML  Draft  Full  Schema,  showing  that  even 
though  the  main  concepts  of  maritime  operations  could  be  captured  it  would  be  necessary  to  introduce  additional 
attributes  and  domain  values.  This  is  trivial  in  the  case  of  extending  existing  enumerations.  Identified  tasks  were 
mapped  to  the  C2LG.  The  results  of  this  activity  were  published  in  [20]. 

Lead  Nation:  Turkey. 

Participating  Nations:  Belgium,  Canada,  France,  Norway. 

2. 5.2.4  MSG-085  Joint  Mission  Planning  CIG 

The  JMP  CIG  was  formed  to  investigate  how  C-BML/MSDL  could  be  used  in  support  of  joint  service  and 
coalition  military  mission  planning,  particularly  how  C-BML-enabled  planning  tools  could  be  used  to  evolve 
operational  plans  and  orders,  which  can  be  evaluated  using  Faster-Than-Real-Time  (FTRT)  simulations. 
Reference  was  made  to  two  significant  NATO  documents: 

•  Allied  Joint  Doctrine  for  Operational-Level  Planning  (AJP-05)  [27];  and 

•  The  Comprehensive  Operations  Planning  Directive  (COPD)  [28]. 

These  determine  the  conventional  NATO  processes  for  joint  mission  planning. 

The  JMP  CIG  looked  at  how  MSDL  and  C-BML  could  be  used  to  assist  both  the  operational  planning  and  the 
technical  support  communities.  In  particular,  attention  was  paid  to  how  MSDL  and  C-BML  can  be  used  to 
support  the  planning  phase  (4b)  of  the  Operational-Level  Planning  Process  (OLPP)  which  forms  part  of  the 
COPD  particularly  at  the  Joint  Force,  Military  Component  command  levels  and  echelons  below. 

The  CIG  has  developed  processes  to  support  the  OLPP  whereby  consistent  sets  of  orders  can  be  developed 
across  echelons  in  a  collaborative  manner  using  C-BML-enabled  simulations  and  analysis  tools.  Different 
Courses  Of  Actions  (COAs)  developed  as  C-BML  orders,  e.g.  at  Brigade  level,  are  executed  in  simulations  to 
help  Commanders  select  optimal  COAs.  These  COAs  are  in  turn  developed  by  lower  echelon  component 
Commanders  using  simulation  support  and  their  results  fed  back  or  back-briefed  to  the  higher  echelon  command 
for  verification  and  approval. 

This  process  is  illustrated  in  Figure  2-6,  below. 
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Figure  2-6:  Collaborative  Joint  Mission  Planning  Process. 


The  JMP  CIG  aimed  to  investigate  metrics  which  could  be  used  to  help  evaluate  alternative  plans  for  the  main 
functional  areas  required  for  mission  planning,  e.g.  time  to  reach  objective,  expected  attrition,  and  degree  of 
logistics  support  required. 

A  separate  strand  was  to  investigate  potential  tools  that  could  be  used  to  support  JMP  concepts.  These  tools 
included  analysis  and  simulation  tools: 

•  Tools  for  Operational  Planning  Functional  Area  Service  (TOPFAS); 

•  One  Semi-Automated  Forces  (OneSAF); 

•  Joint  Semi-Automated  Forces  (JSAF); 

•  Aide  a  la  Planification  d’Engagement  Tactique  terrestre  (APLET); 

•  Integrated  Gaming  System  (IGS);  and 

•  MAGTF5  Tactical  Warfare  Simulator  (MTWS). 

Technical  solutions  to  support  the  JMP  CIG’s  concept  were  developed  by  the  Infrastructure  CIG. 

Lead  Nation:  Great  Britain. 

Participating  Nations:  Canada,  USA. 


5  Marine  Air  Ground  Task  Force  (MAGTF). 
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2.5.2.5  Technical  MSDL/C-BML  Messaging  Infrastructure  CIG 

The  Infrastructure  CIG  was  responsible  for  identifying,  demonstrating  and  maturing  end-to-end  capabilities 
using  MSDL  and  C-BML  technologies  to  ensure  all  necessary  facilities  would  be  available  for  experimentation/ 
demonstration.  As  such,  it  was  concerned  primarily  with  network  facilities,  MSDL/BML  servers,  and  a  well- 
established  portable  suite  of  systems  for  demonstration. 

Network  concerns  included  use  of  the  Internet,  both  for  system  development  and  integration  and  for  conduct 
of  experiments  and  demonstrations.  Ultimately  this  included  use  of  cellular-based  Internet  to  provide 
stable,  low-cost  access  with  adequate  capacity  for  the  Final  Demonstration  where  wired  Internet  access  was  not 
available  to  MSG-085.  Security  was  provided  by  an  OpenVPN  system,  with  a  server  hosted  by  the  GMU  C4I 
Center.  The  JCHAT  system  also  was  provided  for  coordination. 

This  CIG  also  developed  a  set  of  use-cases  and  a  foundational  architecture  as  a  basis  for  C2SIM  services 
required  for  the  MSG-085  experimentation  activities  to  receive/store  all  MSDL/BML  messages  and  distribute 
them  to  other  participating  systems.  Servers  available  included  the  Scripted  BML  server  (SBMLserver) 
from  GMU  C4I  Center,  the  non-parsing  reimplementation  of  SBMLserver  from  Fraunhofer  FKIE,  and  the 
non-parsing  CBMS  from  Virginia  Modeling  and  Simulation  Center  (VMASC,  who  were  not  able  to  participate 
in  the  Final  Demonstration).  Non-parsing  servers  are  simpler  and  can  have  higher  performance,  but  they  cannot 
support  schema  translation,  a  feature  that  facilitated  interoperating  a  variety  of  C2  and  simulation  systems  in  the 
Final  Demonstration.  During  the  year  before  the  Final  Demonstration,  SBMLserver  was  re-implemented  as 
WISE-SBML  [23],  a  higher-performance  parsing  server  based  on  the  Widely  Integrated  Systems  Environment 
(WISE)  from  Saab  Corporation.  Also  for  the  Final  Demonstration  the  FKIE  server  and  WISE-SBML  were 
linked,  enabling  expanded  service  that  interoperated  the  CIG  Land  Ops  configuration  with  the  Infrastructure 
CIG’s  demonstration  configuration  (see  next  paragraph)  and  the  TALOS  system  operated  by  Spain  in 
Madrid  [24]. 

The  demonstration  configuration  was  intended  to  be  readily  available  and  extensible  for  conferences  and 
for  integration  testing  with  other  elements  of  MSG-085.  It  included  a  Battalion/Brigade -level  C2  systems, 
9LandBMS  from  Saab  Corporation  (which  also  was  used  as  a  surrogate  C2  system  by  US  elements  in  the  Final 
Demonstration,  due  to  unavailability  of  a  compatible  US  system);  the  OneSAF  Computer-Generated  Forces 
(CGF)  constructive  simulation,  used  primarily  for  ground  elements;  the  JSAF  CGF,  the  NATO  Air  C2  system 
ICC,  and  the  air  coordination  system  JADOCS,  used  primarily  for  air  elements;  and  the  WISE-SBML  server. 
This  configuration  has  been  used  in  several  demonstrations,  including  multiple  EITSEC  and  ITEC  events  and 
the  MSG-085  Final  Demonstration. 

Lead  Nation:  USA. 

Participating  Nations:  Great  Britain,  Sweden. 

2. 5.2.6  MSG-085  2RS  CIG 

In  February  2013,  a  new  CIG  was  formed  to  focus  on  the  technical  aspects  of  how  to  produce  and  maintain  a 
coherent  set  of  C2SIM  interoperability  standards,  which  has  proven  to  be  difficult  in  the  past  based  on  feedback 
from  those  familiar  with  the  SISO  C2SIM  interoperability  standardization  efforts. 

One  of  the  main  goals  of  this  activity  was  to  provide  a  comprehensive  set  of  Requirements  and  Recommendations 
(2R)  to  the  standardization  bodies  while  proposing  a  concrete  means  to  produce  the  required  Specifications  (S)  - 
or  2RS.  This  activity  focused  first  on  the  definition  of  a  proposed  standard  development  process  based  on 
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systems  engineering  principles  and  inspired  by  the  existing  process  currently  in  use  by  the  M1P  called  the 
Change  Proposal  Process. 

Another  main  goal  of  the  2RS  C1G  was  to  produce  a  prototype  production  chain  that  implemented  the  proposed 
process.  This  toolset  that  was  developed  made  use  of  existing  M1P  products.  This  prototype  production  chain 
was  used  to  produce  a  usable  set  of  XML  schemata  based  on  requirements  gathered  from  the  other  CIGs. 

The  prototype  production  chain  built  on  the  tools  developed  under  the  Scenario  INitialization  and  Execution 
(S1NEX)  initiative  described  in  greater  detail  in  Chapter  4.  S1NEX  offers  a  simplified  user  interface  to  an  UML 
workspace  wherein  it  is  possible  to: 

•  Manage  requirements; 

•  Specify  data  models  that  can  reuse  existing  model  elements; 

•  Trace  requirements  to  model  elements;  and 

•  Generate  model  products  such  as  documentation,  XML  schemata  and  HLA  FOM  modules. 

If  required,  advanced  users  can  work  directly  with  the  UML  interface. 

The  2RS  C1G  also  worked  on  the  integration  C2S1M  interoperability  standards  with  the  existing  DSEEP  standard 
for  federation  design.  This  work  led  to  establishing  a  draft  C2S1M  DSEEP  overlay  for  the  development  of 
federations  comprised  of  simulation  and  C2  systems. 

The  2RS  C1G  produced  a  draft  C2S1M  interoperability  process  description  document  and  also  demonstrated  the 
S1NEX  production  chain  during  I/ITSEC  2013  at  the  NATO  booth. 

Lead  Nation:  France. 

Participating  Nations:  Canada,  Denmark,  Germany,  Great  Britain,  Netherlands,  Norway,  Turkey,  USA. 


2.6  DELIVERABLES 

Consistent  with  the  MSG-085  Programme  of  Work,  the  MSG-085  Technical  Activity  has  produced  the 
following  set  of  deliverables: 

1)  The  current  MSG-085  Technical  Activity  Final  Report,  including  recommendations  for  the 
standardization  of  C2S1M  interoperability. 

2)  Operational  and  Technical  Requirements  Documents: 

a)  Operational  Concept  Description-Part  1:  Course  of  Action  Analysis  -  Planning  [13]; 

b)  Operational  Concept  Description-Part  II:  Command  Post  Training  [14];  and 

c)  Technical  Requirements  Specification  for  C2SIM  Interoperability  Standardization  [9]; 

3)  MSG-085  Experimentation  Programme  Documentation  [16]. 

4)  A  Proposed  set  of  Reference  Expressions  for  C2SIM  interoperation  [19]. 
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Chapter  3  -  REQUIREMENTS  FOR  C2SIM  INTEROPERATION 

One  of  the  main  objectives  of  the  MSG-085  Technical  Activity  was  to  establish  a  set  of  operational  and  technical 
requirements  that  could  serve  as  a  basis  for  subsequent  standards  development.  Toward  this  goal,  two  separate 
sub-groups  were  formed: 

•  The  Operational  Sub-Group  (OSG);  and 

•  The  Technical  Sub-Group  (TSG). 

These  groups  coordinated  to  ensure  that  the  operationally  relevant  requirements  were  identified  by  the  OSG  and 
served  as  the  primary  inputs  to  the  TSG  for  the  derivation  of  the  set  of  requirements  that  could  then  be  used  for 
the  purposes  of  standards  development.  This  chapter  describes  the  work  that  was  conducted  toward  this 
objective. 


3.1  OPERATIONAL  REQUIREMENTS 

The  OSG  has  produced  several  key  outputs  including  two  OCD  documents.  In  addition,  the  OSG  has  established 
a  set  of  operational  use-cases  that  contributed  to  the  definition  of  the  scope  and  high  level  requirements  for 
C2SIM  interoperability  with  respect  to  the  areas  and  domains  that  were  considered. 

In  general,  an  OCD  document  describes  a  proposed  system  in  terms  of  the  user  needs  it  will  fulfill, 
its  relationship  to  existing  systems  or  procedures,  and  the  ways  it  will  be  used.  The  OCDs  are  used  to  obtain 
consensus  among  the  acquirer,  developer,  support,  and  user  agencies  on  the  operational  concept  of  a  proposed 
system.  The  OCD  focuses  on  communicating  the  user’s  needs  to  the  developer  and  the  developer’s  ideas  to  the 
user  and  other  interested  parties.  The  OCD  first  describes  the  current  situation  and  system(s)  that  are  used  and 
elaborates  the  needs  for  an  upgraded  or  new  system,  summarising  limitations  that  exist  in  the  current  situation 
and  identifying  differences  associated  with  different  states  or  modes  of  operation.  Then  the  new  system  is 
described  in  terms  of  one  or  more  operational  scenarios  illustrating  the  role  of  the  new  or  modified  system, 
its  interaction  with  users,  its  interface  to  other  systems  and  all  states  or  modes  identified  for  the  system. 

The  following  sections  summarize  the  two  OCDs  produced  by  the  MSG-085  Technical  Group. 

3.1.1  Operational  Concept  Description  -  Course  of  Action  Analysis 

This  OCD  [13]  addresses  the  use  of  both  C-BML  and  MSDL  standards  for  Course  Of  Action  Analysis  (COAA), 
which  is  part  of  national,  and  coalition  Military  Decision-Making  Processes  (MDMP)  and  more  specifically 
“wargaming”  activities. 

Currently,  the  majority  of  Command  Posts  perform  COAA  with  little  use  of  simulation  systems.  The  wargaming 
is  mainly  a  force  ratio  assessment  activity  and  the  systems  supporting  the  MDMP  are  mainly  information 
systems.  Nevertheless,  there  are  few  systems  that  are  able  to  support  the  C2  staff  for  the  analysis  of  future 
situations,  which  have  become  increasingly  complex.  However,  it  is  conceivable  to  envision  that  there  will  be 
many  more  systems  able  to  support  MDMP  in  the  future. 

In  addition,  the  MDMP  supports  collaboration  poorly  and  is  performed  sequentially  without  involvement  of 
subordinate  units.  The  distinction  between  ‘Cold  planning’  and  ‘Hot  planning’  is  clearly  stated.  The  first  deals 
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with  the  execution  of  MDMP  during  peace  time  to  identify  the  better  response  against  a  probable  threat. 
The  second  is  perfonned  during  military  operations  and  is  time  constrained. 

Ten  operational  requirements  are  identified  and  described  to  enhance  the  current  situation  without  introducing 
additional  delays.  They  are  proposed  to: 

•  Reduce  C2  and  simulation  operators’  workload; 

•  To  shorten  the  time  needed  to  make  the  systems  ready; 

•  To  reduce  the  learning  curve; 

•  To  diminish  mistakes  introduced  by  operators;  and 

•  To  downsize  cost. 

These  system  requirements  are: 

•  C2  systems  should  provide  native  functionality  to  manage  simulation  execution  remotely; 

•  An  evaluation  context1  should  be  introduced  to  enable  the  C2  staff  to  define  and  work  concurrently  on 
different  COAs; 

•  An  evaluation  context  should  be  re-usable  to  enable  the  C2  staff  to  update  an  existing  COA; 

•  C2  system  should  request  a  verification  of  an  evaluation  context  and  its  completeness; 

•  C2  system  should  request  simulation  outputs  dealing  with  a  specific  evaluation  context; 

•  Exchanged  information  should  specify  the  doctrine  chosen  for  different  forces; 

•  Exchanged  information  should  be  consistent  with  the  simulation  capabilities  (e.g.  simulations  can 
handle  a  limited  set  of  tasks  and  expressions  which  are  listed  within  the  evaluation  context); 

•  Exchanged  information  should  address  the  combined  arms  (e.g.  artillery,  logistics,  signals); 

•  Simulation  DTG  (Date  Time  Group)  should  not  constrain  the  C2  time;  and 

•  Exchange  of  information  should  be  fully  automated  (i.e.  simulation  becomes  a  black  box). 

These  requirements  are  the  basis  for  the  description  of  a  new  system  or  federation  of  C2  and  simulation  systems. 
The  interactions  between  the  federates  are  described  to  illustrate  the  functions  of  the  proposed  operational 
planning  procedure  that  improves  understanding  at  multiple  levels,  identifies  risks  early  and  provides  more 
detailed  feedback. 


i 


An  evaluation  context  introduces  measures  and  other  parameters  that  allow  for  the  relative  comparison  of  different  COAs. 
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Figure  3-1:  View  of  Proposed  System  and  Interactions  for  Operational  Planning. 


3.1.2  Operational  Concept  Description  -  Command  Post  Training 

Reference  [14]  describes  the  operational  concept  for  Command  Post  training.  In  Command  Post  training  the 
following  users  of  the  training  system  may  be  identified,  who  are  all  under  control  of  the  Exercise  Director 
(EXDIR)  with  their  Directing  STAFF  (DISTAFF). 

•  TA  -  Training  Audience,  the  trainees. 

•  HICON  -  Plays  the  role  of  the  trainees’  Commanders  and  is  under  control  of  DISTAFF. 

•  FLANCON  -  The  Flanking  (Neighbouring)  Forces  of  the  Trainees  (under  control  of  DISTAFF). 

•  LOCON  -  Provides  the  interface  between  the  TA  and  the  simulation.  FOCON  receives  orders  sent  by 
the  TA  and  translates  them  into  commands  for  the  simulated  forces.  In  addition,  FOCON  dynamically 
reports  simulation  results  to  the  TA.  FOCON  is  under  control  of  DISTAFF  for  exercise  control. 

•  OPFOR  -  Plays  the  role  of  the  enemy  during  the  training  exercise. 

•  White  Cell  is  comprised  of  role  players  that  play  all  incidents  or  events  that  are  not  handled  by  the 
simulation  system  (under  control  of  DISTAFF). 

One  primary  TA  is  considered,  although  in  some  Nations,  multiple  training  audiences  are  sometimes  targeted. 
In  the  case  of  multi-level  training,  some  Nations  also  consider  the  possibility  of  training  the  FOCON  or  FIICON 
with  the  primary  TA. 

Although  there  are  currently  a  variety  of  C2S1M  integration  levels  in  the  different  Nations,  in  the  most  basic 
current  situation  the  users  all  use  their  native  (C2)  systems  and  communication  means  without  the  help  of  new 
C2SIM  interoperability  concepts.  A  “swivel  chair  interface”  is  used  where  both  commands  to  the  simulation 
systems  and  reports  coming  from  the  simulation  systems  are  handled  manually.  The  orders  are  sent  via  the 
Combat  Net  Radio  system  among  the  different  levels  of  command  (Brigade,  Battalion  and  Company)  as  shown 
in  Figure  3-2.  Orders  that  are  to  be  simulated  are  displayed  on  the  FOCON  C2  systems  where  operator(s) 
transform(s)  the  level  of  the  order  into  a  level  that  can  be  executed  by  the  simulation. 


STO-TR-MSG-085 


3-3 


REQUIREMENTS  FOR  C2SIM  INTEROPERATION 


organization 


<&> 

1 


Organic  communication  means 
(Combat  Wet  Radio,  MIP) 

Exercise  control 

Simulation  input/output 

C2  terminal  (MMI) 


DISTAFF 


Sim  terminal  (MMI) 


Operator/  Swivel  chair 


Operator 


TA 


LOCON 


HICON 

D 

'  f 


Figure  3-2:  Current  Typical  Command  Post  Training  Environment. 


The  OCD  elaborates  on  the  need  for  automating  information  flows  among  C2  and  simulation  systems  and 
summarizes  limitations  and  drawbacks  of  existing  systems.  A  proposed  system  that  represents  a  first  step  toward 
addressing  these  issues  is  elaborated  in  the  OCD  and  shown  in  Figure  3-3.  In  this  figure  the  swivel  chair 
interface  has  been  removed  and  the  number  of  simulation  terminals  has  been  reduced  since  the  operators  utilize 
only  their  C2  systems.  A  C2S1M  gateway  is  shown  in  the  figure,  but  it  can  be  expected  that  in  the  future  it  will 
not  be  required  since  C2  and  simulation  systems  will  be  able  to  be  interfaced  directly. 
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Figure  3-3:  Proposed  First  Step  for  Command  Post  Training  Environment. 


Since  most  existing  military  constructive  simulations  are  capable  of  executing  only  low  level  orders  (e.g.  Platoon 
and  below),  LOCONs  still  are  necessary  for  transforming  higher  level  orders  (e.g.  Company  level  orders)  to 
orders  that  can  be  executed  by  the  simulation  (e.g.  Platoon  level).  In  the  future,  as  available  CGFs  become  more 
intelligent,  it  is  to  be  expected  that  type  of  order  transformation  will  be  automated  and  will  become  a  feature  of 
more  and  more  simulation  systems.  This  future  capability  is  reflected  in  the  proposed  architecture  for  a  future 
Command  Post  training  enviromnent  shown  in  Figure  3-4  where  the  LOCONs  no  longer  are  needed;  the  TA  use 
their  C2  systems  that  are  directly  interfaced  to  the  simulation. 
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Figure  3-4:  Proposed  Future  Command  Post  Training  Environment. 


In  the  longer-term,  it  is  possible  to  imagine  that  OPFOR  and  FLANCON  orders  also  will  be  transformed  from 
the  level  at  which  they  are  issued  by  the  DISTAFF  to  a  level  that  can  be  executed  by  simulation  systems, 
consistent  with  the  architecture  depicted  in  Figure  3-5.  Building  such  an  environment  will  be  a  complex 
environment  because  it  requires  a  level  of  sophistication  of  CGFs  that  generally  does  not  exist  today,  as  it 
requires  that  the  simulated  forces  act  sensible  and  in  a  tactically  correct  manner.  At  present,  this  is  generally  not 
possible  at  the  Battalion  level  and  above.  Therefore  the  first  area  where  this  can  be  expected  should  be  when  the 
TA  is  at  Company  level  and  below. 
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Figure  3-5:  Proposed  Future  CP  Training  Environment  w/OPFOR  and  FLANCON  in  DISTAFF. 

The  OCD  presents  an  initial  set  of  operational  requirements,  based  on  a  set  of  use-cases  that  are  relevant  for 
three  phases  in  the  MDMP  that  are  distinguished,  the  preparation  phase,  execution  phase  and  evaluation  phase. 


3.2  DOMAIN-SPECIFIC  CONSIDERATIONS 

This  section  describes  issues,  requirements  and  concerns  that  are  related  to  specific  domains. 

3.2.1  Air  Operations 

Technologies  such  as  the  Coalition  Battle  Management  Language  (C-BML)  provide  for  interoperability  among 
C2,  simulation  and  autonomous  systems.  As  stated  in  the  POW  [3],  the  requirements  for  communication 
between  C2  and  autonomous  systems  are  in  many  aspects  similar  to  those  for  communication  between  C2 
and  simulation  systems.  In  particular,  the  AAO  C1G  considered  use-cases  for  experimentation  involving 
autonomous  aerial  assets  such  as  Unmanned  Aerial  Vehicles  (UAV).  In  addition,  this  C1G  performed  analyses 
and  established  C2S1M  interoperability  requirements  for  the  air  domain. 

Earlier  work  on  air  operations  by  MSG-085  and  its  predecessor,  MSG-048,  has  examined  specific  issues  relating 
to  representing  higher  level  air  operations  C2  information  such  as  Air  Tasking  Orders  (ATO),  Airspace  Control 
Orders  (ACO)  and  Airspace  Control  Means  Requests  (ACMR)  using  C-BML.  This  work  has  included 
integration  of  air  planning  and  tasking  tools  including  NATO’s  Integrated  Command  and  Control  system  (ICC) 
into  a  heterogeneous  C2SIM  federation.  The  AAO  CIG  established  requirements  and  integrated  simulated 
Fixed-Wing  (FW),  Rotary-Wing  (RW)  air  vehicles  and,  in  particular,  Unmanned  Aircraft  Systems  (UAS)  into  a 
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representative,  networked  air  operations  environment.  Aircraft  simulation  was  performed  principally  by  the  Joint 
Semi-Automated  Forces  (JSAF)  constructive  simulation. 

The  AAO  C1G  has  been  able  to  draw  on  experience  gained  in  earlier  Canadian  national  research  on  the  use  of 
agents  to  support  the  use  of  autonomous  UAS  in  a  net-centric  environment.  The  C1G  also  investigated  how 
C-BML  could  be  used  to  direct  lower-level,  more  dynamic  air  tasking  such  as  air-to-air  refuelling,  troop 
deployment/recovery  using  helicopters  and  close  air  support. 

One  of  the  main  goals  of  CIGs  was  to  reach  a  stage  whereby  new  capabilities  developed  under  the  C1G  activities 
could  be  integrated  with  the  work  of  the  other  CIGs  as  part  of  the  2013  MSG-085  experimentation  activity 
leading  to  the  MSG-085  Final  Demonstration  event. 

The  AAO  C1G  has  worked  on  C-BML  expressions  with  the  aim  of  implementing  current  and  future  air 
operations  capability  using  C-BML  and  to  help  inform  the  S1SO  C-BML  PDG  in  its  work.  For  instance,  if  an 
operational  message  is  required  which  cannot  be  formulated  in  the  current  instantiation  of  C-BML,  and  then 
these  requirements  are  fed  through  to  the  C-BML  PDG  for  consideration  in  future  standards  developments. 
Similar  work  has  been  undertaken  with  MSDL. 

A  number  of  operational  messages  have  been  covered.  Three  terms  that  are  well-defined  for  air  operations  are 
particularly  important: 

•  Airspace  Control  Means; 

•  Airspace  Control  Orders;  and 

•  Air  Tasking  Orders  (ACMs,  ACOs  and  ATOs). 

Respectively  these  correspond  to  geographical  overlay  components,  overlays,  i.e.  collections  of  ACMs,  and 
collections  of  aircraft  missions  relating  to  the  ACOs.  Two  main  ACO/ATO  formats  are  used,  these  are  US 
Message  Text  Format  (USMTF)  and  NATO  APP-ll(C)  (ADatP-3)  and  they  differ  only  in  minor  details. 
NATO’s  Integrated  Command  and  Control  (ICC),  an  air  operations  planning  tool,  has  been  used  to  prepare  the 
‘raw  material’,  the  ACMs/ACOs/ATOs,  for  these  investigations.  Other  air  operations  planning  and  coordination 
tools  have  also  been  used  for  related  work.  A  basic  requirement  established  by  the  AAO  CIG  for  the  current 
work  is  that  the  C2  system  should  not  be  specially  modified  for  this  work,  hence  the  standard  operational 
message  formats  are  used  and  separate  message  translators  provided. 

Figure  3-6  shows  the  relationship  among  ACMs,  ACOs  and  ATOs  and  indicates  which  have  been  implemented 
in  the  AAO  CIG  testbed  architecture. 
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Figure  3-6:  C-BML-Enabled  Air  Operations:  Operational  Messages  Covered. 


The  study  work  has  been  supported  by  a  number  of  experiments  using: 

•  National  and  NATO  operational  planning  and  execution  tools:  NATO  ICC,  TBMCS,  JADOCS  and  a 
UAV  ground  control  station; 

•  Various  simulations,  principally  JSAF  but  also  OneSAF  and  a  generic  UAV  simulation; 

•  C-BML/MSDL  middleware:  Coalition  Battle  Management  Services2  (CBMS)  and  the  Scripted  Battle 
Management  Language  server3  (SBMLserver); 

•  C-BML  translator  applications  for  legacy  C2  and  simulation  -  various  CAN-GBR  developments;  and 

•  A  Dynamic  Multi-cast  Virtual  Private  Network  to  permit  secure  multi-national  distributed 
experimentation  to  take  place. 

The  experimentation  architecture  has  led  to  the  design  of  an  infrastructure  and  process  description  to  support  the 
needs  of  Coalition  air  operations  experiments. 


3.2.2  Land  Operations 

The  CIG  Land  Operations  has  specified,  developed  and  demonstrated  improved  C-BML  capabilities  for  land- 
focused  training  and  planning  purposes.  More  specifically,  the  CIG  has  identified  and  defined  a  set  of 
information  elements  and  messages  required  to  implement  the  following: 

•  Exchange  of  messages  among  legacy  C2  systems  and  simulations  systems  according  to  operational 
interfaces  and  flow  of  information; 

•  Operational  ORDer  (OPORD),  including  new  C-BML  tasks  to  address  stabilization  phase  of  operations; 


2 

CBMS  developed  by  the  Virginia  Modeling,  Analysis  and  Simulation  Center. 

3 

SBML  developed  by  the  George  Mason  University  C4I  Center. 
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•  Land  manoeuvre  situation  reports,  recce  reports  and  logistics  reports  (sustainment  of  fuel,  personnel, 
ammunition  consumption  and  status  of  devices);  and 

•  Request/order/report  for  artillery  support. 

The  work  on  these  improvements  has  resulted  in  the  identification  of  specific  issues  and  concerns  for  Land 
operations  that  could  eventually  be  generalized  to  other  domains.  Those  issues  are  described  in  this  section,  with 
examples/illustrations  took  from  the  CIG  Land  Operations  experimentation. 

3.2.2. 1  Task  Parameters 

The  parameters  needed  for  each  task  are  not  standardized  in  the  C-BML  schema  and  should  not  be  standardized, 
because  expected  missions  parameters  for  one  simulation  may  depend  on  the  task  verb,  the  hierarchical  level  of 
the  tasked  unit  and  its  unit  type.  Mission  parameters  may  also  vary  from  one  C2  system  to  another  one  (because 
of  different  doctrines). 

For  example  in  SWORD  (French  simulation),  the  RECCE  task  needs  only  a  route  (line)  when  a  combat  Platoon 
is  tasked,  but  the  RECCE  task  needs  an  objective  area  and  two  boundaries  when  a  combat  Company  is  tasked. 

To  exchange  tasks  between  systems  without  ambiguities  and  to  automatically  process  them,  the  CIG  Land  Ops 
CIG  recommendation  is  to  capture  those  constraints  with  standardized  business  rules  templates. 

3.2.2.2  Task  Geometry 

The  task  geometry  issue  is  different  from  task  parameters  because  it  deals  with  the  meaning  of  the  geometry 
attached  to  a  task.  The  APP-6  symbols  embedded  the  meaning  of  the  geometry  (for  example,  a  block  ‘T’  mission 
is  made  of  a  front  line  where  the  unit  should  stand  and  wait  for  the  enemy  -  upper  part  of  the  T  -  and  a  back 
location  -  bottom  point  of  the  T)  -  but  the  current  C-BML  schema  is  not  designed  to  support  APP-6  symbols  for 
action  tasks,  and  it  contains  a  limited  set  of  codes  describing  the  role  of  a  geometry  attached  to  a  task. 
To  continue  with  the  Block  mission  example: 

•  SIR  (French  C2  at  Battalion  and  Company  levels)  defines  it  with  an  oriented  line  or  an  area; 

•  SWORD  (French  simulation)  requires  an  area;  and 

•  MIL-STD-2525B  and  APP-6  define  it  with  a  ‘T’  symbol. 

In  order  to  simplify  future  interoperation  of  C-BML  compliant  systems,  C-BML  could  propose  a  solution  that 
enables  some  automatic  conversions  between  the  tasks  geometries  expected  by  the  systems.  These  automatic 
conversions  can  be  done  by  the  systems  themselves  or  maybe  by  the  infrastructure  if  the  conversions  are  very 
simple  and  don’t  depend  on  the  tactical  situation. 

3.2.2.3  Observation  Reports 

During  implementation  of  the  C-BML  gateway  for  the  SIR  system,  an  issue  has  been  identified  inside  the 
observation  reports  dealing  with  Detected  or  Recognized  observations.  Those  observations  describe  the  unit’s 
type  and  its  level,  but  do  not  provide  the  unit’s  identifier  (only  known  when  the  observation  is  an  Identification), 
or  a  track  identifier.  Without  an  identifier,  when  a  unit  would  observe  the  same  enemy  unit  twice,  the  C2 
gateway  will  have  to  generate  a  new  ID  for  this  detection,  and  two  objects  will  be  displayed  on  the  SIR  system 
instead  of  one.  The  recommendation  is  to  add  a  track  identifier  in  the  observation  report. 
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3.2.2.4  C2  Systems  Overwhelmed 

The  C2  systems  can  be  overwhelmed  by  the  C-BML  messages  sent  by  simulation,  when  simulation  runs  faster 
than  real  time.  This  effect  also  has  been  noticed  for  observation  reports  when  simulation  runs  at  real  time. 
To  avoid  this  issue,  the  simulation  must  time  regulate  message  generation  according  to  operational  procedures. 

3.2.2. 5  Systems  are  Very  Sensitive  with  Time 

Two  issues  were  identified: 

•  Future  DTG  (Date  Time  Group)  messages  are  cancelled  and  thus  not  displayed  by  C2  system;  and 

•  Past  DTG  orders  are  cancelled  by  the  simulation  and  thus  not  displayed. 

While  it  was  not  a  problem  for  demonstrations,  this  should  be  taken  into  account  in  the  future  standard. 
The  initialization  of  systems  may  share  for  example  a  consistent  DTG  that  may  also  be  updated  during  the 
scenario  execution. 

3.2.3  Maritime  Operations 

C-BML  was  initially  created  with  a  focus  on  Land  Operations.  Earlier  work  by  MSG-085  and  its  predecessor, 
MSG-048,  also  included  Air  Operations. 

Maritime  Operations  are  very  different  from  Land  Operations  in  nature.  While  land  tasks  are  typically  given  in  a 
sequential  order  (i.e.  do  Task  1,  then  Task  2)  against  a  known  enemy  or  terrain  objective,  some  maritime  tasks 
are  given  without  identifying  the  enemy.  A  typical  task  is  to  patrol  an  area:  to  make  sure  the  enemy  does  not 
enter  the  area  or  to  use  force  against  any  enemy  within  the  area.  Due  to  the  nature  of  such  a  task,  there  are 
implicitly  several  tasks  running  in  parallel: 

•  Patrol  the  area  until  a  surface  vessel  is  detected; 

•  If  a  surface  vessel  is  detected,  suspend  patrolling,  identify  the  surface  vessel; 

•  If  the  surface  vessel  is  identified  as  hostile,  force  it  to  leave  the  area;  and 

•  If  showing  hostile  intent,  attack  in  accordance  with  Rules  Of  Engagement  (ROE). 

In  this  scenario,  only  the  patrolling  task  has  a  specified  start  and  end  time  and  an  associated  geographic  area. 
The  other  three  tasks  are  conditional  and  depend  on  the  results  of  these  tasks  and  on  the  ROE.  These  conditional 
tasks  add  complexity  to  the  modelling.  Firstly,  modelling  tasks  in  C-BML  is  not  based  on  acting  on  results  of 
actions,  so  this  requires  a  new  approach  for  modelling.  Secondly,  from  a  simulation  perspective,  it  is  hard  to 
decide  when  a  condition  that  evokes  another  task  has  occurred.  Besides  conditional  tasks  or  other  suspended 
tasks,  there  are  inherent  tasks  the  vessel  should  execute  continuously  due  to  the  nature  of  Naval  Warfare,  such  as 
maintaining  a  Recognized  Maritime  Picture. 

The  Maritime  C1G  used  formatted  naval  operational  message  specifications  stated  in  NATO  APP- 11(B)  and 
example  orders  as  input  to  develop  a  set  of  Information  Exchange  Requirements  (IER).  More  specifically, 
the  CIG  identified  a  set  of  information  elements  in  OPGEN,  OPTASK  ASUW  and  OPT  ASK  AMPHIB  relevant 
to  digital  orders  and  their  execution  by  a  simulation.  The  IER  were  captured  in  form  of  a  System/Sub-system 
Specification  (SSS)  document  that  specifies  requirements  covering  the  following  areas: 

1)  Maritime  Task  Organization,  including  Officer  in  Tactical  Command  (OTC)  location.  This  can  be 
extended  to  include  warfare  Commanders. 


STO-TR-MSG-085 


3-11 


REQUIREMENTS  FOR  C2SIM  INTEROPERATION 


organization 


2)  Basic  control  features,  such  as:  way  points,  routes  and  patrol  areas. 

3)  Movement  of  forces  in  formation,  i.e.  sector  screen. 

4)  A  set  of  maritime  tasks,  e.g.  patrolling. 

5)  Naval  Gunfire  Support. 

Items  1-3  were  successfully  modelled  using  the  C-BML  Full  Schema.  Additional  domain  values  to  existing 
enumerations  were  added  when  needed.  When  modelling  the  task  organization  in  C-BML,  it  was  decided  to 
distinguish  between  the  equipment  (hardware)  and  the  organization  (personnel),  consistent  with  JC31EDM 
modelling  practices.  This  is  often  ignored  in  maritime  orders.  Regarding  item  4,  task  modelling  the  results 
divided  in  three  equally  sized  categories: 

•  Successfully  mapped; 

•  Schema  required  the  addition  of  new  domain  values;  and 

•  Schema  required  structural  changes/additions. 

For  modelling  Naval  Gunfire  Support,  the  Maritime  C1G  proposed  the  use  of  the  Schema  elements  developed  by 
the  Land  Ops  C1G  for  Indirect  Fire  Support. 


3.3  TECHNICAL  REQUIREMENTS 

A  Technical  Requirements  Specification  was  produced  [9]  and  served  as  the  starting  point  for  subsequent 
requirement  analyses.  Figure  3-7  shows  the  overall  organization  of  requirements  and  subsequent  document 
structure.  This  document  was  produced  using  automated  documentation  generation  capabilities  that  were  offered 
by  the  UML  enviromnent  used  by  the  MSG-085  Technical  Sub-Group  to  establish  an  initial  set  of  requirements 
for  C2S1M  interoperation.  For  scenario  initialization,  requirements  were  reverse-engineered  from  the  existing 
MSDL  Version  1.0  specification.  For  scenario  execution,  initial  requirements  were  taken  from  the  S1SO  C-BML 
Phase  2  Drafting  Group  and  then  complemented  by  inputs  provided  by  the  Air,  Land  and  Maritime  Operations 
CIGs. 
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Figure  3-7:  C2SIM  Interoperability  Technical  Requirements  Overview. 

As  shown  in  the  figure,  assumptions,  constraints  and  dependencies  also  were  captured  as  part  of  this  initial 
requirements  analysis  activity.  An  example  of  a  constraint  is  the  mandated  re-use  of  the  M1P  JC31EDM  as 
the  primary  source  for  vocabulary.  In  addition,  throughout  the  analysis  issues  were  identified  and  recorded. 
An  example  of  an  issue  is  the  need  to  align  the  MSDL-derived  and  C-BML  requirements  for  the  definition  of 
units. 
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The  following  sections  provide  an  overview  of  the  latest  version  of  the  MIP  products,  namely  the  MIP 
Information  Model  (M1M)  and  associated  toolset,  and  how  these  products  can  be  utilized  to  build  a  requirements- 
based,  sustainable,  standardized  C2S1M  interoperability  model  and  derived  standard  products.  The  M1M  is  the 
slated  successor  to  the  JC31EDM  and  incorporates  many  improvements  and  features  described  below. 


4.1  MIP  PRODUCTS  OVERVIEW 

4.1.1  The  MIP  Information  Model1 

The  MIP  is  a  joint  effort  of  29  Nations  and  NATO  to  support  interoperability  of  C2  systems.  Its  standardization 
efforts  cover  technical  as  well  as  procedural  and  operational  aspects  of  the  information  exchange.  The  current 
MIP  specification,  the  MIP  baseline  3.1,  is  based  on  the  JC31EDM,  which  has  been  ratified  under  NATO 
STANAG  5525.  In  recent  years,  the  MIP  has  been  working  on  a  successor  to  the  well-established  JC3IEDM  that 
combines  the  rich  operational  content  of  the  JC3IEDM  with  state-of-the-art  technologies.  This  new  model, 
called  MIP  Information  Model  (MIM)  breaks  with  several  design  constraints  of  the  JC3IEDM  while  at  the  same 
time  maintaining  all  the  operational  concepts.  Thus,  the  MIM  has  operationally  the  same  expressiveness  as  the 
JC3IEDM.  The  first  and  most  obvious  difference  between  the  JC3IEDM  and  the  MIM  is  the  choice  of  modelling 
language.  While  the  JC3IEDM  is  described  as  an  entity-relationship  model  using  the  IDEF1X  notation,  the  MIM 
is  described  as  a  class  model  in  the  UML. 

This  difference  has  several  implications: 

•  Platform  Independence:  Since  the  JC3IEDM  was  modelled  in  a  way  that  it  directly  maps  to  a  database 
schema  that  can  be  used  with  the  Data  Exchange  Mechanism  of  MIP,  the  JC3IEDM  can  be  seen  as  a 
PSM.  This  makes  it  more  difficult  to  create  other  representations  of  the  JC3IEDM  such  as  XML 
schemata  or  ontologies,  even  though  these  mappings  have  been  done  in  the  past.  The  MIM,  in  contrast, 
has  been  designed  from  the  beginning  to  support  the  approach  of  MDA  and  as  such  can  be  considered  a 
PIM.  Concepts  such  as  primary  keys  or  globally  unique  identifiers  have  been  removed  from  the  model 
and  will  be  re-introduced  when  generating  PSMs. 

•  Clarified  Semantics:  As  a  PSM  with  a  long  history,  the  semantics  of  the  JC3IEDM  are  not  always 
easily  comprehensible,  since  the  structure  of  the  model  is  influenced  by  technical  constraints  and  design 
rules  as  well  as  operational  requirements.  Much  effort  has  been  spent  on  clarifying  the  meaning  of  the 
MIM.  Toward  this  goal,  all  of  the  associations  of  the  MIM  have  been  evaluated  with  respect  to  their 
definitions,  role  names  and  navigability.  Furthermore,  a  rewording  of  all  definitions  has  resulted  in  a 
better  comprehensibility  of  the  intended  meaning  and  usage  of  attributes  and  classes.  One  of  the  most 
important  additions  was  the  use  of  stereotypes  on  attributes  to  categorize  them  according  to  the 
UN  CEF ACT  class  words. 

•  Formal  Consistency  Rules:  In  the  JC3IEDM  several  usage  and  consistency  rules  (often  called  business 
rules)  have  been  expressed  in  tabular  form  and  free  text.  In  the  MIM,  most  of  these  rules  have  been 
addressed  by  making  the  structure  of  the  model  more  explicit.  For  example,  rules  constraining  the 
allowed  values  in  attribute  combinations  have  been  remodelled  such  that  only  valid  combinations  are 


1  See:  https://mipsite.lsec.dnd.ca/Public%20Document%20Library/MIM-Information_Sheet.pdf. 
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expressible  in  the  model.  In  the  cases  where  this  was  not  possible  or  desirable,  the  rules  have  been 
formalized  using  the  OCL. 

•  Documentation:  The  documentation  of  the  M1M  is  currently  under  development.  The  first  chapters 
already  have  been  written.  The  documentation  will  be  part  of  the  M1M,  using  object  diagrams  to 
illustrate  the  intended  use  of  the  model.  Some  scripts  have  been  implemented  to  ensure  the  consistency 
of  the  examples  and  the  underlying  class  model.  Generating  the  full  documentation  from  the  model 
automatically  will  ensure  an  up-to-date  and  consistent  documentation,  subsequent  to  model  changes. 

Another  important  difference  between  the  JC31EDM  and  the  MIM  is  the  conceptual  separation  of  the 
infonnation  model  from  the  exchange  interface  specification.  In  the  future,  MIP  will  deliver  multiple  small 
interface  specifications,  each  covering  one  specific  operational  capability.  These  specifications  will  all  be  based 
on  the  MIM,  but  will  use  only  a  small  sub-set  of  the  model’s  elements.  This  so-called  capability-based  approach 
allows  the  MIP  Community  to  be  much  more  open  to  input  from  other  communities.  In  the  JC3IEDM  the 
addition  of  a  single  attribute  or  value  to  a  coded  list  would  require  the  release,  implementation  and  test  of  a  new 
baseline.  In  the  future,  these  modifications  will  only  appear  in  those  interface  specifications  that  are  based  on  the 
modified  part  of  the  respective  model. 

In  addition  to  being  platform  independent,  the  MIM  has  some  additional  features  that  make  it  easier  to 
understand  and  use.  One  of  its  key  features  is  the  separation  of  metadata  (e.g.  time,  source,  security  classification), 
information  groups  (e.g.,  overlays),  and  operational  core  elements  (e.g.  objects,  actions,  plans/orders). 
This  means  that  the  core  elements  can  be  described  in  a  stateless,  source-independent,  and  context-free  manner 
and  consequently  allows  for  a  much  cleaner  and  stricter  specification. 

For  example,  previously  a  more  complicated  relationship  occurred  since  any  object  in  the  JC3IEDM  may  have 
multiple  statuses.  This  allows  for  multiple  reports  for  the  same  object  made  by  different  observers,  as  well  as 
keeping  track  of  the  change  of  the  status  over  time.  A  status  report  may  also  refer  to  a  future  desired/estimated 
status  for  planning  purposes. 

So  the  MIM  took  the  approach  to  remove  these  different  dimensions.  Consequently,  the  association  between 
Object  and  Status  became  a  one-to-one  relationship  and  the  status  attributes  have  been  merged  with  the  Object 
hierarchy.  Since  adding  these  different  dimensions  back  to  the  model  is  a  simple  transformation,  the  MIM  did 
not  lose  any  expressiveness. 

The  high-level  core  elements  are  depicted  in  Figure  4-1.  Since  all  operational  concepts  of  the  JC3IEDM  have 
been  retained,  this  view  looks  very  similar  to  a  view  of  all  independent  entities  of  the  JC3IEDM.  The  core  of  the 
model  comprises  an  extensive  hierarchy  of  battle  space  objects  such  as  Organisations,  Materiel,  Facilities, 
Features,  etc.  This  taxonomy  contains  approximately  150  different  classes. 
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Figure  4-1 :  MIM  Core  Classes. 


Another  part  of  the  model  allows  the  specification  of  Actions  along  with  their  Resources,  Objectives  and  Effects. 
At  the  time  of  writing,  the  Action  structure  of  the  MIM  is  under  discussion  and  will  be  revised  in  accordance 
with  feedback  from  the  C-BML  community. 

The  Location  hierarchy  includes  absolute  and  relative  points,  lines,  surfaces  and  volumes.  One  of  the  many 
differences  between  the  MIM  and  the  JC31EDM  is  that  in  the  MIM  Locations  are  modelled  as  part  of  a 
composition  relationship  (or  strong  association),  which  means  that,  according  to  UML  semantics,  location 
instances  cannot  be  re-used.  This  gives  locations  the  notion  of  value  objects,  i.e.  they  are  defined  by  their  exact 
coordinates  and  do  not  need  an  additional  identifier  in  the  PSM. 

Since  it  is  assumed  that  metadata  is  applicable  to  all  kinds  of  information  and  all  information  may  be  grouped, 
information  groups  and  metadata  are  not  linked  explicitly  to  the  core  elements  of  the  MIM.  Instead, 
a  transformation  will  create  the  necessary  links  when  generating  the  PSMs.  This  greatly  reduces  the  number  of 
associations  in  the  MIM  and  thus  greatly  improves  the  comprehensibility  and  clarity  of  the  model. 

4,1.2  MIP  Change  Process  and  Tools 

The  experience  of  maintaining  and  extending  an  extensive  information  model  in  a  multi-national  environment 
has  shown  that  it  is  essential  to  keep  track  of  all  changes  that  modify  the  model  in  order  to  be  able  to  trace  them 
back  to  their  authors  and  rationales.  Furthermore,  the  established  process  of  developing  the  model  requires  that 
all  changes  and  their  rationale  be  accepted  unanimously.  Thus,  in  a  community-driven  specification  process, 
change  proposals  have  to  be  discussed  and  documented  prior  to  applying  them  to  the  model.  To  ensure  that  a 
proposed  change  can  be  applied  to  the  model  without  manual  intervention  once  it  has  been  accepted  by  all 
stakeholders,  Fraunhofer  FKIE  has  developed  a  tool  that  accepts  change  proposals  in  an  XML  format  as  input  to 
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the  tool  that  applies  them  to  the  model.  While  performing  the  formally  described  changes  on  the  model,  the  tool 
also  enforces  several  consistency  checks  and  notifies  the  user  of  possible  derivations  from  design  rules  and  best 
practices.  Since  the  tool  can  be  used  to  validate  a  change  proposal  prior  to  putting  it  up  for  vote,  it  is  obvious  that 
an  accepted  change  proposal  will  be  applicable  to  the  model  without  requiring  manual  intervention  and  thus  the 
possibility  of  introducing  errors  is  nil. 

Another  major  advantage  of  this  process  is  that  it  creates  the  potential  for  parallel  work.  Since  each  change 
proposal  only  specifies  particular  desired  modifications  to  the  model,  the  tool  performing  these  changes  can 
identify  overlaps  in  conflicting  change  proposals.  Even  though  this  may  seem  trivial,  it  is  the  basis  for  the 
previously  described  capability-based  approach  in  which  each  capability  package  defines  a  small  sub-set  of  the 
M1M  and  then  modifies/extends  this  sub-set,  as  required. 

The  MIP  has  developed  and  maintains  several  different  tools  that  support  the  previously  mentioned  change 
process,  as  shown  in  Figure  4-2. 


CP  Editor:  The  CP  Editor  is  a  tool  that  can  be  used  to  load  and  browse  the  MIM  and  to  create  change  proposals. 
It  still  is  in  early  stages  of  development  but  already  has  the  capability  to  visualize  minimal  sub-views  of  the 
MIM.  A  minimal  sub-view  is  defined  as  all  classes,  attributes  and  associations  that  are  required  to  be  compliant 
with  the  MIM.  The  idea  of  a  minimal  sub-view  is  similar  to  the  concept  of  a  Transactional  as  described  by 
OMGs  Shared  Operational  Picture  Exchange  Sendees  (SOPES).  The  graphical  editor  is  shown  in  Figure  4-3. 
The  left  side  of  the  editor  is  a  tree  view  of  the  model,  showing  all  packages,  classes  and  attributes  as  well  as  all 
tagged  values  of  the  currently  selected  element.  At  the  bottom,  all  associations  of  the  currently  selected  element 
are  shown.  The  center  and  the  right  side  of  the  editor  are  two  different  views  on  the  sub-view.  The  center  is  a 
graphical  view  with  the  explicitly  included  classes  shown  in  light  blue  and  the  required  classes  shown  in  gray. 
The  right  side  is  a  more  textual  view  of  the  same  sub-view  definition. 
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Figure  4-3:  MIP  Model  Editor. 


CP  Processor:  The  CP  Processor  applies  a  formal  change  proposal  to  a  model  and  can  execute  change  proposals 
created  using  the  CP  Editor.  Currently,  two  types  of  change  proposals  are  supported: 

1)  A  sub-view  definition  (also  called  Business  Object  Change  Proposal)  is  a  change  proposal  that  creates  a 
minimal  sub-view  which  contains  all  elements  defined  in  the  change  proposal.  By  default,  the  minimal 
sub-view  does  not  include  optional  attributes.  However,  the  sub-view  definition  can  define  optional 
elements  explicitly,  as  well  as  suppressing  mandatory  attributes  by  setting  them  to  a  fixed  value. 

2)  A  formal  change  proposal  describes  the  intended  changes  both  formally  and  textually.  These  formal 
changes  are  basic  operations  such  as  “create”,  “modify”  or  “delete”  on  UML  elements  such  as  packages, 
classes,  attributes,  stereotypes  and  associations. 

Transform  Tool:  According  to  OMGs  MDA  approach,  a  P1M  such  as  the  MIM  can  be  transformed  into  a 
PSM.  The  transform  tool  supports  multiple  transformations  that  can  be  applied  to  the  model  in  order  to 
(re)introduce  certain  aspects  or  patterns  in  the  model.  For  example  it  is  possible  to  add  the  value  “unknown”  to 
all  enumerations  in  order  to  allow  users  to  express  that  a  value  may  not  be  known. 

As  described  in  the  MSG-085  POW  [3],  one  of  the  objectives  of  MSG-085  was  to  investigate  the  optimal  use  of 
the  MIP  products  for  C2S1M  standardization.  This  activity  entailed  coordination  with  the  MIP  concerning  the 
use  of  the  MIP  products  and  included: 

•  The  use  of  emerging  MIP  models; 

•  The  use  of  the  evolving  MIP  toolset; 


STO-TR-MSG-085 


4-5 


THE  USE  OF  MIP  PRODUCTS  FOR  C2SIM  STANDARDIZATION 


organization 


•  Interaction  with  the  MIP  to  ensure  a  proper  understanding  concerning  the  use  of  the  model  and  tools; 
and 

•  Requests  from  MSG-085  for  changes  to  the  MIP  model  and  toolset. 

The  change  requests  were  primarily  aimed  toward  satisfying  C2SIM  specific  requirements  but  also  included 
suggestions  for  improvements  to  the  MIP  model  itself.  Some  of  these  suggestions  were  accepted  and  included 
in  the  official  MIP  product  release.  The  exchanges  between  MSG-085  and  the  MIP  were  channeled  through 
MSG-085  members  acting  as  MIP  Liaisons. 


4.2  A  PROCESS  AND  TOOLSET  FOR  C2SIM  INTEROPERABILITY  STANDARD 
DEVELOPMENT 

The  exchanges  between  the  MSG-085  MIP  liaisons  and  the  MIP  resulted  in  a  productive  collaboration,  including 
the  formation  of  a  CIG  for  exploring  the  elaboration  of  a  process  and  toolset  for  the  management  of  C2S1M 
interoperability  standards  based  on  the  MIP  model  and  tools.  From  2013  on,  this  work  was  conducted  as  part  of 
the  newly  formed  2RS  CIG  (see  Section  2. 5.2. 6).  The  main  goal  of  this  CIG  was  to  define  a  dedicated  process 
and  prototype  tool  chain  for  building  a  sustainable,  extensible  C2SIM  interoperability  standard  based  largely  on 
existing  MIP  tools.  The  CIG’s  combined  efforts  have  produced  the  Scenario  INitialization  and  Execution 
(SINEX)  initiative  that  has  been  identified  by  the  NATO  Communications  and  Information  Agency  (NCIA)  as  a 
potential  part  of  the  future  NATO  C2SIM  Interoperability  solution2.  The  SINEX  approach  is  described  in 
references  [21],  [23]  and  is  summarized  below. 

The  work  performed  included  the  definition  of  a  C2SIM  standard  development  process  and  a  prototype 
production  chain  based  on  the  use  of  the  MIP  products  has  been  proposed. 

The  process  and  production  chain  is  summarized  in  Figure  4-4  and  Figure  4-5.  Figure  4-6  shows  the  proposed 
inputs  and  outputs  for  the  SINEX  process  applied  to  the  C-BML  and  MSD  standards  with  respect  to  existing 
bodies  of  work  in  C2S1M  interoperability.  Figure  4-7  is  a  screenshot  of  the  prototype  tool  that  was  developed  as 
part  of  the  MSG-085  2RS  CIG  activity. 


2 

http://www.dodccrp.org/events/18th_iccrts_2013/post_conference/plenary/jense.pdf. 
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Figure  4-4:  SINEX  Process  Overview. 
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Figure  4-6:  SINEX  Inputs  and  Outputs. 


Figure  4-7:  SINEX  Prototype  Tool. 
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The  SINEX  approach  has  been  suggested  as  a  means  for  ensuring  a  proper  convergence  of  the  C-BML  and 
MSDL  standards.  Preliminary  work  in  this  area  has  shown  that  SINEX  is  feasible  as  a  means  for  defining  and 
evolving  a  combined  C2S1M  interoperability  standard  with  traceability  to  stakeholder  requirements  [22], 
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Chapter  5  -  EXPERIMENTS,  WORKSHOPS  AND  CONFERENCES 

The  experimentation  programme  represents  an  important  part  of  the  MSG-085  programme  of  work. 
The  experimentation  programme  is  comprised  of  a  series  of  events,  primarily  demonstrations.  These  events  have 
several  purposes: 

•  They  confirm  the  operational  relevance  and  measure  the  benefits  of  existing  C2S1M  interoperability 
approaches; 

•  They  identify  limitations  and  areas  of  improvements  of  existing  technologies; 

•  They  help  to  inform  the  broader  community  concerning  the  state-of-the-art  in  C2S1M  interoperability; 
and 

•  Perhaps  the  most  important  of  all,  the  lessons  learned  from  these  events  contribute  to  the  elaboration  of 
a  set  of  recommendations  for  standardization  bodies  that  are  developing  C2S1M  interoperability 
standards. 

This  chapter  summarizes  the  experimentation  events  conducted  by  the  MSG-085  Technical  Activity.  It  also 
summarizes  the  various  communication  and  education  events  that  were  organized  by  and/or  included  significant 
participation  by  MSG-085  members.  In  addition  to  the  events  described  below,  MSG-085  organized  several 
internal  workshops,  including  workshops  on: 

•  Applied  Ontology  for  C2SIM  Interoperation;  and 

•  A  multi-domain  C2SIM  Interoperability  Workshop. 

The  following  sections  highlight  the  events  that  were  held  in  public  forums. 


5.1  EXPERIMENTATION  EVENT  PLANNING  GUIDE 

Consistent  with  the  MSG-085  Programme  of  Work,  the  MSG-085  Technical  Activity  included  an 
experimentation  programme  comprised  of  experiments  and  demonstrations  in  order  to: 

1)  Verify  the  operational  relevance  of  C2SIM  interoperability  standards  such  as  MSDL  and  C-BML; 

2)  To  identify  shortcomings  and  areas  requiring  further  attention;  and 

3)  To  communicate  findings  and  lessons  learned  to  the  broader  community  [2], 

In  order  to  facilitate  the  preparation  and  execution  of  experimentation  and  demonstration  events,  MSG-085 
developed  an  Experimentation  Event  Planning  Guide  (EEPG)  [15]. 

In  addition  to  a  number  of  internal  experimentation  events,  MSG-085  held  public  demonstrations  at  least  twice  a 
year  during  the  course  of  the  MSG-085  Technical  Activity.  In  general,  these  events  took  place  at  the  EITSEC 
and  ITEC  conferences  at  the  NATO  CSO  booth.  The  EEPG  was  useful  for  both  experimentation  events  and 
demonstrations. 

The  EEPG  describes  the  different  types  of  experimentation  events  typically  held  by  Modelling  and  Simulation 
Groups  (MSG)  and  suggests  an  organizational  structure  for  attributing  roles  and  responsibilities  among  the 
different  participants.  Most  importantly,  it  defines  a  set  of  documents  that  generally  are  required  in  order  to 
properly  plan,  execute  and  communicate  the  results  of  the  event. 
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5.1.1  Types  of  Experimentation  Events 

Experimentation  is  the  art,  process  or  practice  of  performing  experiments.  The  underlying  paradigm  of  an 
experiment,  which  is  hypothesis-based,  is  to  manipulate  something  to  see  what  the  result  is.  For  the  purposes  of 
the  MSG-085  Experimentation  Programme,  other  events,  such  as  demonstrations  and  tests  also  were  included  as 
experimentation  events.  The  EEPG  defines  these  different  types  of  possible  experimentation  events  as  follows: 

•  Experiments  -  To  prove  or  disprove  specific  hypotheses  and/or  to  determine  the  relationship  between 
different  things. 

•  Demonstrations  -  To  share  obtained  results  or  demonstrate  proven  capabilities;  Demonstrations  show 
and/or  explain  how  things  work. 

•  Tests  -  To  confirm  a  specific  functionality  or  quality  of  something  based  on  pre-established  pass/fail 
criteria  and  other  metrics. 

The  MSG-085  Experimentation  Programme  consisted  primarily  of  demonstrations. 

5.1.2  Experimentation  Event  Documentation 

The  EEPG  also  specifies  the  basic  components  required  to  properly  document  an  experimentation  event. 
In  short,  event  description  documents  should  include  the  following  elements: 

•  Experimentation  Event  Description  and  Overview  -  A  summary  and  narrative  that  provides  the 
details  associated  with  the  specific  experimentation  event  (demonstration  harness)  to  include,  but  not 
limited  to,  the  venue,  location,  country  participation,  synopsis  of  systems  /  capabilities,  dates,  and 
general  overview  of  goals  and  objective. 

•  Technical  Architecture  Description  and  Overview  -  A  layout,  pictorial  or  drawing  of  the  technical 
architecture  in  terms  of  configuration,  network  resources,  national  systems  and  capabilities.  This  will 
also  include  a  summary  and  narrative  that  provides  the  descriptive  details  associated  with  all  of  the 
components,  interfaces  and  configuration  of  the  experimentation  architecture. 

•  System  Design  Agreements  (SDA)  -  This  description  will  also  include  the  system  design  agreements 
that  stipulate  common  interfaces,  federation  agreements  and  other  conventions. 

•  Operational  Scenario  -  Each  experiment  will  include  an  operational  scenario  that  will  drive  the  event. 
This  section  of  the  appendix  will  include  a  description  of  the  scenario  with  details  of  units,  platforms, 
sensors,  manoeuvre,  geographical  location,  etc.,  and  the  script  that  will  be  followed  during  the 
experiments. 

•  Integration  and  Test  Plan  -  Describes  the  integration  and  test  plan  that  will  allow  for  the  integration, 
verification  and  tracking  of  the  experimentation  capability. 

•  Start-up  and  Execution  Procedures  -  A  description  of  the  procedures  required  to  initialize  the 
experiment  and  execute  the  script. 

•  Facilities,  Equipment  and  Resource  Requirements  -  Information  pertaining  to  what  facilities, 
equipment  and  resources  are  being  utilized  to  support  the  experimentation  event. 

•  Schedule  -  A  milestone  chart,  graphic  or  slide  that  depicts  the  high  level  actions,  meetings,  test  events, 
workshops,  telephone  conferences,  execution  events,  etc.  that  support  the  experiment  event. 

•  Evaluation  -  After  each  experimentation  event,  the  lessons  learned  and  technical  and  operational 
evaluations  will  be  captured. 
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•  Brochures,  Leaflets,  Posters  and  Presentations  -  All  the  documents  and  publicity  that  are  generated 
to  socialize  the  experiment  event. 

5.1.3  Experimentation  Event  Organization 

The  EEPG  defines  an  organizational  structure  to  ensure  that  the  various  roles  and  responsibilities  are  allocated 
and  tracked.  These  roles  include: 

•  An  Experimentation  Event  Lead  (EEL); 

•  A  Elosting  Nation  (EIN); 

•  A  Technical  Coordinator  (TC); 

•  An  Operational  Coordinator  (OC);  and 

•  A  Communication  Coordinator  (CC),  as  shown  in  Figure  5-1 . 


XP  Event  Lead 


Technical 

f  Operational 

COORDINATOR 
^ _ 

COORDINATOR 

J 

f - 

Communication 

- > 

COORDINATOR 

J 

Figure  5-1:  Experimentation  Event  Organizational  Structure. 


The  roles  and  corresponding  responsibilities  are  described  in  Table  5-1. 


Table  5-1:  Experimentation  Event  Roles  and  Responsibilities. 


Role 

Responsibilities 

Experimentation  Event  Lead  (EEL) 

Experimentation  Architecture  Description 

Manage  and  Track  Schedule/Risks 

Hosting  Nation  (HN) 

Experimentation  Facilities,  Equipment  and  Resource 
Requirements 

Experimentation  Schedule 

Technical  Coordinator  (TC) 

Technical  Architecture  and  System  Design  Agreements 
(SDA) 

Experimentation  Integration  and  Test  Plan 

Experimentation  Evaluation  (Technical) 
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Role 

Responsibilities 

Operational  Coordinator  (OC) 

Operational  Scenario 

Experimentation  Start-up  and  Execution  Procedures 
(with  support  from  TC) 

Experimentation  Evaluation  (Operational) 

Communication  Coordinator  (CC) 

Brochures,  Leaflets,  Posters,  Presentations 

5.2  APRIL  2011  -  BML  RESEARCH  SYMPOSIUM 

In  spring  2011,  the  George  Mason  University  C4I  Center  organized  a  BML  Research  Symposium  that  was  held 
on  the  Friday  April  8  201 1  following  the  S1SO  S1W  Spring  2011  in  Boston.  The  purpose  of  this  symposium  was 
to  present  a  community  update  on  leading-edge  work  in  BML  in  the  form  of  a  series  of  invited  talks,  (see  agenda 
in  Annex  A.  1).  The  event  was  chaired  by  Dr.  Stan  Levine  who  headed  a  Program  Committee  with  representatives 
from  NATO  MSG-085,  SISO  C-BML  and  the  US  Army. 


5.3  MAY  2011  -  ITEC  DEMONSTRATION 

The  first  MSG-085  demonstration  took  place  during  ITEC  2011  and  focused  on  the  use  of  MSDL  for  the 
initialization  of  multiple  C2  and  simulation  systems  comprising  a  C2S1M  federation,  (see  Figure  5-2). 


ITEC  2011  MSDL  DEMONSTRATION 


APLET 


Common 
MSDL  File 


OneSAF 


MilitaryScenario  Definition  Language  (MSDL)  for  simulation  initialization 


SUMMARY 


Able  to  initialize  multiple  systems  with 
common  MSDLfile. 

Need  more  tools  to  support  and 
manage  MSDL  data. 

Some  nations  considering  the  use  of 
MSDLto  initialize  C2  systems. 


Figure  5-2:  ITEC  2011  MSG-085  Scenario  Initialization  Demonstration. 
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5.3.1  Goals 

The  goals  of  the  demonstration  event  are  the  following: 

1)  Validate  that  the  MSDL  standard  could  be  used  to  merge  coalition  initialization  inputs  and  support 
consistent  initialization  across  a  coalition  simulation  federation.  Initial  coalition  participants  included 
members  from  France,  Germany,  Great  Britain,  Spain  and  the  United  States; 

2)  Establish  an  engineering  process  and  rhythm  for  coalition  collaboration  using  MSDL  and  C-BML 
technologies  within  the  MSG-085  organization;  and 

3)  Provide  lessons  learned  back  to  MSG-085  participants  in  the  use  of  MSDL  technologies  in  support  of 
both  simulation  and  C2  initialization. 

5.3.2  Architecture 

An  independent  distributed  architecture  was  used  by  the  individual  Nations  to  provide  their  task  organizations 

within  independent  MSDL  formatted  files  to  the  MSDL  integrator.  The  MSDL  integrator  then  integrated  the  task 

organization  and  provided  a  final  MSDL  file  back  to  all  participants  for  import  into  their  systems. 

5.3.3  Results 

The  demonstration  development  activity  produced  the  following  feedback  to  the  MSG-085  activity: 

1 )  MSDL  Integration  tools  are  lacking,  but  could  be  developed  in  a  short  timeframe  building  on  common 
tools  such  as  Excel,  Notepad++,  and  Visual  Basic  Scripting. 

2)  In  addition  to  the  MSDL  standard  data  model  federation  agreements  were  necessary  to  ensure  common 
interpretation  of  the  data. 


5.4  DECEMBER  2011  -  I/ITSEC 

The  demonstrations  performed  during  I/ITSEC  2011  extended  the  ITEC  2011  demonstration  described  above. 
The  event  focused  on  scenario  initialization  including  pre-planned  orders  provided  in  C-BML  format  and 
referenced  within  the  MSDL  file.  This  demonstration  also  included  MSDL/BML  servers  using  different 
information  exchange  infrastructures  while  encouraging  a  maximum  participation  from  the  MSG-085 
Nations.  As  shown  in  Annex  A.2,  the  use-case  being  demonstrated  was  that  of  Distributed  Coalition  Training. 
The  demonstration  event  included  three  demonstrations  based  on  three  different  vignettes: 

1 )  Air  Reconnaissance; 

2)  Combined  Operations  and  Logistics;  and 

3)  Ground  Manoeuvre. 

The  focus  of  the  demonstrations  was  on  leveraging  both  MSDL  and  C-BML  for  scenario  initialization  and 
execution,  respectively.  Multiple  “Capability  Harnesses”  were  provided  to  support  the  Nations’  requirements 
for  exchanging  information  among  C2  system,  simulation  and  tools  for  scenario  initialization  and  execution. 
Demo  Harness  1  was  based  on  the  GMU  Scripted  Server  Infrastructure  and  Demo  Harness  2  utilized  the 
Coalition  Battle  Management  Service  (CBMS)  infrastructure  provided  by  the  US  Joint  and  Coalition 
Warfighting  (JCW). 
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5.4.1  Goals 

The  goals  of  the  demonstration  event  were  the  following: 

1)  There  is  a  need  to  be  able  to  initialize  heterogeneous  C2  and  simulation  systems  in  a  coherent  and 
systematic  manner.  MSDL  can  contribute  to  accomplishing  this.  This  is  the  subject  of  continuing  work 
and  includes  suggested  extensions  and  amendments  to  both  SISO  C-BML  and  MSDL  standards, 
consistent  with  the  MSG-085  Programme  of  Work. 

2)  It  is  important  to  be  able  to  conduct  experimentation,  and  ultimately  operational  planning  and  training, 
using  systems  that  are  not  co-located  but  distributed,  potentially  across  several  Nations.  In  principle, 
it  should  not  matter  whether  systems  are  co-located,  but  in  practice  coordination  is  more  difficult  so 
processes  and  tools  are  required  to  coordinate  and  facilitate  distributed  activities.  To  this  end,  during  the 
demonstration,  C-BML  systems  were  connected  from  nodes  in  Great  Britain,  Norway  and  the  USA. 

3)  Real  Command  Post  training  activities  involve  more  than  combat-related  tasks.  Therefore,  the  addition 
of  logistics  reports  allowed  for  a  more  realistic  capability  that  added  realism  to  the  training  environment. 

Finally,  one  of  the  goals  of  this  event  was  to  demonstrate  how  the  use  of  M1P  products,  such  as  a  JC31EDM 
database,  can  be  employed  as  part  of  an  information  exchange  infrastructure  that  can  facilitate  the  exchange 
among  systems  that  potentially  use  different  schemas  to  define  their  message  sets  and  other  documents. 

5.4.2  Architecture 

Each  of  the  three  vignettes  employed  an  independent  distributed  MSDL/BML  Server  implementation  and 
architecture.  The  figures  below  depict  the  operational  and  technical  view  of  each  of  the  vignettes. 


ICC/JADOCS 

Servers 


JSAF 


UK  C-BML 
Translators 


BCIP 


C-BML 


Norway 


NorTAC 


VRForces 


C-BML 


;c-bml 


UAV  Controller 
&  JSAF 


Figure  5-3:  Air  Reconnaissance  Vignette. 
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5.4.3  Results 

In  addition  to  the  results  recorded  from  ITEC  2011  several  positive  conclusions  were  drawn  from  the  vignette 
development  and  demonstration  focused  activities.  The  conclusions  include: 

•  Two  independently  developed  MSDL/C-BML  messaging  infrastructures  were  successfully  used  to 
service  initialization/re-initialization  and  order-based  message  traffic  to  a  variety  of  C2  and  simulation 
clients; 

•  The  MSDL  transmittal  file  was  successfully  extended  with  logistics  and  C-BML  related  data;  and 

•  The  use  of  MSDL/C-BML  within  the  simulation  and  C2  initialization  process  led  to  shorter  scenario 
preparation  times  than  previous  experience  without  the  MSDL  technology. 

Many  C2  orders  provided  to  the  simulations  in  C-BML  format  require  additional  artificial  intelligence  within  the 
simulations  to  execute  them  with  minimal  import  and  transformation  of  the  order  set. 


Operational  Overview 


Technical  Architecture  Overview 
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SITAWARE 


SIMULATION 


SWORD 
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ORQUE 


Figure  5-4  :  Combined  Operations  and  Logistics  Vignette  and  Architecture. 
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Operational  Overview 


Technical  View 
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Figure  5-5:  Ground  Manoeuvre  Vignette  and  Architecture. 


5.5  SEPTEMBER  2012  -  BML  RESEARCH  SYMPOSIUM 

Organized  by  the  George  Mason  University  C4I  Center  with  support  from  with  support  from  MSG-085 
members,  the  2012  BML  Research  Symposium  took  place  during  the  Fall  2012  S1W.  Topics  covered  include: 

•  MSDL/C-BML  alignment; 

•  Operational  Requirements  for  C-BML;  and 

•  C-BML  Standards  Development;  and 

•  C-BML  Messaging  Software,  (see  Figure  5-6  for  symposium  overview  and  Annex  A.3  for  detailed 
agenda). 
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SIS<» 


Simulation  Interoperability 
Standards  Organization 


BML  Research  Symposium  2012 

to  be  held  in  conjunction  with  SISO  SI  W  Fall  2012 

As  in  past  years,  the  symposium  will  consist  of  invited  talks 
focusing  on  new  technologies  with  the  potential  of  supporting 
future  BMLeffortse.g.  MSDL/C-BMLconvergenceand  C-BML 
Phase  2and  beyond.  This  year's  symposium  will  be  held  in 
Orlando  on  Wednesday  12  September,  in  facilities  provided  by 
the  SISO  meeting.  As  with  past  BML  Research  Symposia,  a 
program  committee  will  select  and  invite  speakers,  intendedto 
give  a  balanced  representation  of  leading  edge  work  in  BML. 
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Who:  Anyone  interesting  in  the  future  of  BML 
What:  BML  Research  Symposium 
When:  Wednesday,  12September2012 
Where:  Salon  3,  Fall  SI W 

Why:  Inform  and  update  the  BML  research  commmunity 
and  stakeholders  on  current  and  future  efforts. 


Figure  5-6:  September  2012  BML  Research  Symposium  Overview. 


5.6  NOVEMBER  2012  -  CIG  WORKSHOP 

In  November  of  2012,  MSG-085  held  a  CIG  Workshop  in  Fairfax,  Virginia  in  order  to  share  the  results 
and  findings  of  the  various  CIGs  (see  Workshop  Agenda  in  Annex  A.4).  The  workshop  included  detailed 
presentations  and  demonstrations  with  invitations  to  the  operational  community  to  attend. 

Some  CIGs  provided  live  demonstrations  with  C2  and  simulation  systems  while  other  CIG  presented  the  results 
of  analysis  and  other  paper  studies. 

The  workshop  took  place  over  several  days.  The  first  few  days  involved  final  preparation  while  the  last  day  was 
reserved  for  the  actual  live  demonstrations  and  briefings,  as  shown  in  the  figure  above.  Briefings  from  each  CIG 
presented  the  findings  and  lessons  learned  from  their  respective  activities. 

These  results  also  were  shared  with  the  broader  community  during  I/ITSEC  2012,  during  which  a  series  of 
demonstrations  were  held  at  the  NATO  booth  (see  Section  5.7).  In  addition,  several  MSG-085  Nations  shared 
the  results  and  findings  by  participating  in  the  NATO  MSG-1 19  C2SIM  Interoperability  Workshop  (see  Section 
5.8)  that  took  place  during  I/ITSEC  2012.  The  results  of  the  CIG  efforts  conducted  in  2012  also  were  presented 
during  the  Spring  2013  SISO  Interoperability  Workshop  (SIW),  (see  Section  5.9). 


5.7  DECEMBER  2012  -  I/ITSEC  DEMONSTRATION 

In  early  2012  NMSG-085  formed  a  number  of  CIGs: 
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•  Technical  Infrastructure; 

•  Maritime  Operations; 

•  Land  Operations; 

•  Joint  Mission  Planning;  and 

•  Autonomous  Air  Operations. 

Each  group  comprising  operational  and  technical  specialists  from  across  the  MSG  whose  principal  aim  was  to 
study  requirements,  use-cases  and  identify  solutions  relating  to  the  use  of  C-BML  and  MSDL  in  these 
domains.  An  important  aim  of  all  the  CIGs  has  been  to  work  towards  developing  supporting  knowledge  and 
complementary  skills  which  were  used  in  MSG-085’s  final  experimentation  programme  and  contributed  to  the 
group’s  body  of  results  and  findings. 

5.7.1  Goals 

The  goals  of  the  demonstration  event  were  the  following: 

1)  To  illustrate  how  it  is  possible  to  initialize  heterogeneous  C2  and  simulation  systems  in  a  coherent  and 
systematic  manner. 

2)  To  show  the  potential  for  conducting  operational  planning  and  training,  using  systems  that  are  not 
co-located  but  distributed,  potentially  across  several  Nations. 

3)  To  demonstrate  the  added  realism  of  Command  Post  training  activities  by  including  more  than 
combat-related  tasks.  Therefore,  the  addition  of  logistics  reports  allowed  for  a  more  realistic  training 
environment. 

4)  To  show  how  the  C2S1M  interoperability  technologies  developed  by  the  Nations  can  be  utilized  across 
several  domains,  including  land  operations  and  also  air  operations  that  involved  the  use  of  operational 
ACO  and  ATO. 

5.7.2  Architecture 

Figure  5-7  and  Figure  5-8  show  the  operational  context  and  technical  architecture  for  the  Air  Operations 
demonstration.  Figure  5-9  and  Figure  5-10  show  the  operational  context  and  technical  architecture  for  the  Fand 
Operations  demonstration,  Figure  5-11  and  Figure  5-12  show  the  operational  context  and  technical  architecture 
for  the  Air/Fand  Recce  demonstration. 
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Figure  5-7:  BML-Enabled  Air  Ops  Context. 
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Figure  5-8:  BML-Enabled  Air  Ops  Architecture. 
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Figure  5-9:  Land  Ops  Demo  Context. 
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Figure  5-11:  Air/Land  Recce  Demo  Context. 
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Figure  5-12:  Air/Land  Recce  Demo  Architecture. 
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5.7.3  Results 

The  demonstrations  were  well-attended  and  were  repeated  several  times.  They  included  participation  from 
Nations  participating  remotely  by  connecting  over  internet. 


5.8  DECEMBER  2012  -  MSG-119  C2SIM  INTEROPERABILITY  WORKSHOP 

Chaired  by  France,  and  organized  by  the  NATO  MSG-085  Technical  Group,  the  NATO  MSG-119  C2S1M 
Interoperability  Workshop  took  place  on  Wednesday  December  5th  2012  during  the  Interservice  Industry 
Training  Simulation  and  Education  Conference  (I/ITSEC)  that  was  held  from  December  3-6th  2012. 
The  MSG-119  workshop  was  attended  by  approximately  60  participants  representing  about  20  Nations.  During 
the  first  part  of  the  workshop  a  panel  of  technical  experts  provided  overviews  of  the  C2S1M  interoperability 
standards  (MSDL  and  C-BML)  and  on  the  use  of  C-BML  messaging  infrastructures  to  exchange  information 
among  C2  and  simulation  systems.  Then  a  series  of  operational  demonstrations  were  given  to  clearly  illustrate 
the  cost-savings,  time -savings  and  other  benefits  of  leveraging  C2-to-simulation  interoperability  standards  and 
also  to  show  that  technologies  such  as  MSDL  and  C-BML  are  rapidly  maturing  toward  a  level  consistent  with 
operational  employment  by  stakeholders. 

Annex  A.6  presents  the  workshop  agenda  and  background  information.  The  MSG-119  Technical  Evaluation 
Report  provides  a  summary  of  the  workshop  activities  and  discussions,  and  also  offers  a  perspective  on  the  state- 
of-the-art  of  C2S1M  interoperability  standards  [8]. 


5.9  APRIL  2013  -  SPRING  SISO  INTEROPERABILITY  WORKSHOP 

During  the  Spring  2013  SISO  Interoperability  Workshop,  MSG-085  members  presented  a  series  of  papers 
describing  the  results  and  findings  from  the  C1G  activities  described  in  the  previous  sections.  These  papers 
included  work  from  the  Air,  Land  and  Maritime  domains  and  other  C2S1M  related  work,  (see  Table  5-2). 

Table  5-2:  MSG-085  CIG  Papers  Presented  at  Spring  2013  SISO  Workshop. 


13S-S1W-002 

A  Systems  Engineering  Approach  to  M&S  Standards  Development: 
Application  to  the  Coalition  Battle  Management  Language 

13S-S1W-009 

C2SIM  Interoperability  Experimentation  for  Autonomous  Air 

Operations 

13S-S1W-022 

Towards  a  Maritime  Domain  Extension  to  Coalition  Battle 

Management  Language:  Initial  Findings  and  Way  Forward 

13S-S1W-031 

Lessons  Learned  from  NMSG-085  CIG  Land  Operation 

Demonstration 

13S-S1W-032 

Low-Level  Battle  Management  Language 

13S-S1W-039 

Next  Steps  in  MSDL/C-BML  Coordination  for  Convergence 
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5.10  JUNE  2013  -  C2SIM  INTEROPERABILITY  SESSION  DURING  ICCRTS  2013 

During  its  Wachtberg  meeting  in  February  2013,  MSG-085  agreed  to  support  a  BML  Symposium  in  conjunction 
with  the  International  Command  and  Control  Research  and  technology  Symposium  2013  (ICCRTS-2013)  and 
designated  Dr.  Mark  Pullen  of  the  GMU  C4I  Center  to  contact  the  management  of  1CCRTS-20 1 3  and  work  out  a 
plan  for  achieving  this.  During  that  process,  ICCRTS  General  Chair  Dr.  David  Alberts  offered  to  create  a  Track 
addressing  C2SIM  Interoperability.  Dr.  Hans  Jense  of  NC1A  agreed  to  provide  a  kick-off  talk  and  was  co-opted 
by  ICCRTS  as  a  plenary  speaker,  which  had  the  commendable  effect  of  exposing  the  benefits  of  C2SIM  and  the 
work  of  MSG-085  to  other  attendees.  Other  authors  and  presenters  recruited  from  academia,  government  and 
industry  for  the  Track  are  listed  below.  Many  of  these  presentations  were  made  by  MSG-085  participants. 
Technical  papers1  and  industry  presentations  are  shown  in  Table  5-3  and  Table  5-4. 

Table  5-3:  MSG-085  Papers  Presented  at  ICCRTS  2013. 


Kevin  Heffner,  Nico  Bau,  Michael  Gerz:  An  Approach  Using  MIP  Products  for  the  Development  of  the 
Coalition  Battle  Management  Language  Standard 

Saikou  Diallo,  Ross  Gore,  Anthony  Barraco:  Integrating  CPOF,  JSAF  and  ONESAF  through  CBMS 

Kevin  Heffner  ,  Kevin  Gupton:  Implementing  a  Standards  Development  Framework  for  the  Coalition  Battle 
Management  Language 2 

Per  Gustavsson:  Developing  a  Command  and  Control  Methodology  for  Increased  Automation  -  Using 
Simulation  to  Improve  Mission  Planning  and  Execution 

Per  Gustavsson,  Michael  Hieb:  The  Operations  Intent  and  Effects  Model:  A  Command  and  Control 
Methodology  for  Increased  Automation 

J.  Mark  Pullen,  Douglas  Comer,  Per  Gustavsson,  Magnus  Gronkvist:  Incorporating  C2SIM  Interoperability 
Services  into  an  Operational  C2  System 

Thomas  Remmersmann,  Ulrich  Schade,  Alexander  Tiderko:  Interacting  with  Multi-Robot  Systems  Using  BML 
Shim,  Lee,  and  Cho:  Analysis  for  Information  Exchange  Capability  of  Battlefield  Networks  Using  M&S 


Table  5-4:  Industry  Presentations  Presented  at  ICCRTS  2013  C2SIM  Session. 

Jonas  Hallstrom,  Saab:  C2  in  Tactical  Operations:  Train  as  you  Fight 

Kevin  Galvin,  Thales:  Potential  Exploitation  of  C2-Sim  Interoperability  Research  to  Support  the  UK 
Warfighter 

LtCol  Bernardo  Neto,  Brazilian  AF:  C2-Simulation  Studies  in  ITA-GMU  Testbed 
Robert  Wittman,  MITRE:  Command  Web:  Operational  Web-Enabled  C2-Simulation 


1  For  more  details,  see  http://www.dodccrp.org/events/18th__iccrts_2013/post_conference/html/home.html. 

2 

Nominated  for  Symposium  Best  Paper. 
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5.11  DECEMBER  2013  -  I/ITSEC  DEMONSTRATION3 

MSG-085  held  a  series  of  demonstrations  highlighting  the  benefits  of  the  latest  technologies  for  C2SIM 
interoperability  to  the  Warfighter.  Battalion  and  Brigade  level  Joint  and  Combined  Mission  Planning 
demonstrations  were  given  at  the  NATO  booth.  These  demonstrations  illustrated  how  these  technologies  could 
be  used  to  perform  mission  planning  in  a  more  effective,  collaborative  fashion.  Another  series  of  demonstrations 
were  given  that  provided  an  overview  of  the  S1NEX  process  and  toolset:  a  collaborative  approach  to  developing 
and  maintaining  C2S1M  interoperability  standards. 

5.11.1  Goals 

The  goals  of  the  demonstrations  were: 

•  To  show  illustrate  how  C2S1M  interoperability  solutions  also  can  lead  to  new  ways  of  performing 
military  activities  such  as  joint  and  combined  mission  planning;  and 

•  To  present  a  new  approach  for  specifying,  building,  evolving  and  sharing  C2S1M  interoperability 
solutions  using  an  engineering  process. 

5.11.2  Architecture 

The  operational  context  and  technical  architecture  are  shown  in  Figure  5-13  and  Figure  5-14,  respectively.  They 
are  the  same  as  those  utilized  for  the  final  demonstration  that  took  place  the  following  week. 


Figure  5-13:  l/ITSEC  2013  Scenario. 


3 

See  NATO  press  release  at:  http://www.cso. nato.int/page.asp?id=1682. 
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Figure  5-14:  l/ITSEC  2013  Architecture. 


5.11.3  Results 

The  demonstrations  were  well-attended  and  were  repeated  several  times.  The  mission  planning  exercises 
included  participation  from  Nations  participating  remotely  by  connecting  over  internet. 

The  S1NEX  demonstration  illustrated  how  it  is  possible  to  rapidly  generate  an  XML  schema  based  on  a  common 
information  model  using  a  structured  approach  and  a  highly  automated  toolset.  The  resulting  XML  schema  then 
can  serve  as  the  basis  for  a  standardized  or  community-specific  C2S1M  information  exchange.  The  S1NEX 
collaborative  approach  to  developing  and  maintaining  C2S1M  Interoperability  standards  demonstrated  military 
information  can  be  shared  efficiently  among  C2  and  simulation  systems  for  the  purposes  of  performing  military 
enterprise  activities.  The  S1NEX  demonstration  was  based  on  the  architecture  and  prototype  described  in 
Chapter  4  and  illustrated  in  Figure  4-6  and  Figure  4-7. 


5.12  DECEMBER  2013  -  FINAL  DEMONSTRATION,  US  ARMY  MCBL 

MSG-085  presented  a  demonstration  featuring  military  operational  use  of  C2  systems  interoperating  with 
combat  simulations  on  12  Dec  2013.  The  demonstration  was  hosted  by  the  Mission  Command  Battle  Laboratory 
(MCBL)  at  Fort  Leavenworth,  Kansas,  and  featured  six  national  non-US  C2  systems  and  five  national 
simulations,  supported  by  servers  from  two  different  Nations,  linked  into  a  single  system-of-systems.  Standards 
used  were  the  Military  Scenario  Definition  Language  (MSDL),  Coalition  Battle  Management  Language 
(C-BML),  along  with  elements  of  the  JC31EDM. 
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The  operational  focus  of  the  demonstration  was  joint  and  combined  mission  planning,  operating  in  a 
breakthrough  parallel,  collaborative  mode  across  Brigade  and  Battalion  echelons  of  a  multi-national  coalition 
force.  Personnel  and  systems  from  nine  Nations  (23  personnel)  participated  at  Leavenworth  while  personnel 
from  Spain  and  the  United  Kingdom  participated  from  their  home  locations  via  Internet  links.  Military  SMEs 
provided  by  the  MCBL  played  roles  of  Brigade  and  Battalion  Commanders  and  contributed  a  critique  of  the 
operational  employment  that  was  highly  positive  and  also  offered  avenues  for  future  improvement. 

The  demonstration  was  well  attended  by  US  and  international  military  and  supporting  civilian  personnel, 
who  offered  mainly  positive  comment  and  also  recommendations  to  improve  operational  utility,  for  example  the 
need  to  resolve  security  issues  before  deployment.  The  senior  military  attendee  was  Brigadier  General  Thomas 
S.  James,  Director  of  the  US  Army  Mission  Command  Center  of  Excellence,  who  stated  very  positively  that  the 
category  of  systems  demonstrated  by  MSG-085  should  have  an  important  role  in  supporting  a  wide  range  of 
future  military  operations  by  the  US  and  its  coalition  partners. 

5.12.1  Goals 

The  main  purpose  of  the  demonstration  was  to  show  how  C2SIM  interoperation  technologies  can  be  used  to 
facilitate  collaborative  distributed  planning.  In  particular,  the  goal  of  the  demonstration  was  to  show  that  these 
technologies  can  contribute  to  increased  collaboration  among  Brigade  and  Battalion  Commanders  during  COA 
development. 

5.12.2  Architecture 

The  featured  capability  was  Joint  and  Combined  Mission  Planning.  The  architecture  of  the  demonstration 
system-of-systems  that  was  assembled  is  shown  in  Figure  5-15. 
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Figure  5-15:  MSG-085  Final  Joint  and  Combined  Mission  Planning  Demonstration  Architecture. 
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5.12.3  Results 

The  main  results  of  the  demonstration  can  be  summarized  with  respect  to  the  following  achievements: 

•  Network  Sophistication :  The  MSG-085  network  included  two  remote  participants  and  operated  with  two 
linked  servers  and  three  schemata  (C-BML  Full,  while  available  on  the  W1SE-SBML  server,  was  not 
used  by  any  of  the  systems).  This  models  the  sort  of  operation  expected  in  operational  BML  use. 

•  Setup  Process'.  The  MSG-085  systems  came  together  smoothly.  There  were  a  few  problems  but  mostly 
they  “just  worked”. 

•  Audience  Impression :  The  Final  Demonstration  audience  got  the  message  “We  have  an  exciting  new 
capability  and  it  works  very  well  to  improve  some  unmet  needs  of  coalition  C2,  using  interoperable 
simulations.” 

In  short,  MSG-085  succeeded  in  achieving  the  main  demonstration  goal:  proving  the  concept  that  C2S1M  in  the 
form  of  MSDL  and  C-BML  is  ready  to  be  tested  in  real  coalition  operations. 


5.13  JUNE  2014  -  C2SIM  INTEROPERABILITY  SESSION  DURING  ICCRTS 
2014 

Following  the  success  of  the  C2S1M  track  in  1CCRTS-2013,  MSG-085  decided  during  its  Copenhagen  meeting 
in  October  2013  to  support  a  C2S1M  Interoperability  Track  at  1CCRTS-2014,  and  again  turned  to  Dr.  Pullen  to 
coordinate.  Although  Dr.  Alberts  had  not  been  planning  to  repeat  this  topic,  he  readily  agreed  to  add  it.  In  2014 
there  will  be  only  paper  presentations  (no  industry  briefings),  but  nevertheless  the  track  covers  two  full  days 
of  the  conference,  a  new  first  for  BML  technical  meetings.  Again  in  2014,  many  of  the  presentations  are  by 
MSG-085  participants: 

Technical  papers4: 

•  Adam  Brook:  UK  Experiences  and  Lessons  Identified  Using  C-BML  in  Practical  Experiments. 

•  Brett  Burland,  LtCol  Jens  Inge  Hyndoy,  James  Ruth:  Incorporating  C2-Simulation  Interoperability 
Services  into  an  Operational  Command  Post. 

•  Bruno  Gautreau,  Kevin  Heffner,  Ole -Martin  Mevassvik,  Nico  de  Reus,  Lionel  Khimeche:  A  Proposed 
Engineering  Process  and  Prototype  Toolset  for  Developing  C2-to-Simulation  Interoperability  Solutions. 

•  James  Hilton,  Saikou  Diallo,  Ross  Gore:  C2  Agility:  Lessons  Learned from  Research  and  Operations. 

•  Lt  Cdr  Patrick  Lara:  A  Message  Exchange  Protocol  in  Command  and  Control  Systems  Integration, 
Using  the  JC3IEDM. 

•  Francisco  Loaiza,  Steve  Wartik,  John  Thompson,  Dale  Visser,  Edward  Kenschaft:  The  Best  of  All 
Possible  Worlds:  Applying  the  Model  Driven  Architecture  Approach  to  a  JC3IEDM  OWL  Ontology 
Modeled  in  UML. 

•  LtCol  J.  Bernardo  Neto,  Michael  Hieb,  Paulo  Costa:  Agility  through  Automated  Negotiation  for  C2 
Services. 

•  J.  Mark  Pullen,  Lionel  Khimeche:  Advances  in  Systems  and  Technologies  Toward  Interoperating 
Operational  Military  C2  and  Simulation  Systems. 


4  For  more  details,  see:  http://www.dodccrp.org/events/19th_iccrts_2014/post_conference/html/track9.html. 
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•  Thomas  Remmersmann,  Ulrich  Schade,  Alexander  Tiderko:  Commanding  Heterogeneous  Multi-Robot 
Teams. 

•  Samuel  Singapogu:  Opportunities  for  Next  Generation  BML:  Semantic  C-BML. 

•  Robert  Wittman:  OneSAF  as  an  In-Stride  Mission  Command  Asset. 

5.14  OCTOBER  2014  -  C2SIM  INTEROPERABILITY  WORKSHOP 

The  possible  topics  to  be  covered  include: 

•  Overview  of  Key  Military  Enterprise  Activities  addressed  by  C2S1M  Interoperability. 

•  Update  on  C-BML  and  MSDL  Standardization. 

•  Summary  of  MSG-085  Technical  Activity: 

•  Results  and  findings;  and 

•  Recommendations  for  standardization. 

•  Highlighted  use-cases  leveraging  C2-S1M  interoperability: 

•  Successful  use  of  MSDL  and  C-BML  standards;  and 

•  National  and  coalition  experimentation. 

•  Introduction  to  the  Scenario  INitialization  and  Execution  (SINEX)  Initiative. 

•  Present  the  new  NATO  MSG  C2SIM  Interoperability  Technical  Activity. 

5.14.1  Scope 

Through  presentation,  discussion  and  debate,  attendees  will  acquire  knowledge  and  experience  in  the  different 
topic  areas  to  exploit  C-BML  and  MSDL  technologies. 

It  is  expected  that  all  participants  will  develop  a  shared  understanding  of  the  issues  and  opportunities  regarding 
the  use  of  C-BML  and  MSDL  standards  to  ease  C2S1M  interoperability. 

Meeting  proceedings  will  be  produced  including  recommendations  for  NATO  and  the  Nations. 

5.14.2  Registration 

Please  visit  www.cso.nato.int  and  look  for  registration  details  for  MSG-138. 

5.14.3  Agenda 

0830  -  0900:  Registration 

0900  -  0945:  Overview  of  C-BML  and  MSDL  Standards  Development  (USA  /  Dr.  Robert  Wittman) 

0945  -  1030:  History  of  C2SIM  NATO  Activities  (FRA  /  Mr.  Lionel  Khimeche) 

1030 -  1100:  Break 

1 100  -  1 130:  Leavenworth  Demonstration  Operational  Impact  (NOR  /  LtCol  Hyndoy) 
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1130-  1200:  Leavenworth  Demonstration  Technical  Impact  (DEU  /  Mr.  Thomas  Remmersmann) 
1200-  1330:  Lunch 

1330  -  1400:  Foundational  Infrastructure  (USA  /  Dr.  Mark  Pullen) 

1400  -  1430:  C-BML  Maritime  (NOR  /  Mr.  Ole  Martin  Mevassvik) 

1430  -  1500:  VBS2,  C-BML  FOM  and  MSDL  (GBR  /  Dr.  Kevin  Galvin) 

1500-  1530:  Break 

1530  -  1600:  Mission  Command  Embedded  Simulation  Systems  Services  (USA  /  Mr.  Amit  Kapadia) 
1600  -  1630:  Brainstorming  and  wrap-up  (USA  /  Dr.  Robert  Wittman) 
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Chapter  6  -  LESSONS  IDENTIFIED  AND  LESSONS  LEARNED 

The  NATO  Lessons  Learned  Handbook  distinguishes  among:  lessons  identified,  lessons  learned  and  lessons 
learned  information  as  follows  [17]: 


Lesson  Identified 
(LI) 

This  is  a  mature  observation  with  a  determined  root  cause  of  the  observed  issue  and  a 
recommended  remedial  action  and  action  body,  which  has  been  developed  and  proposed  to 
the  appropriate  authority. 

Lesson  Learned 
(LL) 

An  improved  capability  or  increased  performance  confirmed  by  validation  when  necessary 
resulting  from  the  implementation  of  one  or  more  remedied  actions  for  a  lesson  identified. 

Lesson  Learned 
Information 
(LLI) 

Any  information  that  is  generated  as  part  of  a  LL  process  as  well  as  information  generated 
after  activities  that  is  not  formally  part  of  a  LL  process  such  as  after  action  reviews,  periodic 
mission  reports,  first  impression  reports,  final  exercise  reports,  trip  reports,  hot  wash  up 
output,  meeting  minutes,  etc.  (proposed  definition). 

This  chapter  describes  the  LI,  LL  and  LLI  from  the  various  experimentation  events,  communication  events  and 
other  activities  such  as  analysis  or  modelling. 


6.1  VARIABILITY  OF  C2SIM  INTEROPERATION  REQUIREMENTS  (LL) 

C2SIM  Interoperation  requirements  vary  across  services,  Nations  and  also  depend  on  the  themes  and 
focus  areas  of  specific  training,  mission  rehearsal  or  experimentation  events. 

Inherent,  differences  in  the  manner  in  which  military  operations  are  conducted  by  different  forces  must  be  taken 
into  account  in  the  development  of  C2SIM  interoperability  standards.  This  lesson  learned  has  resulted  in  the 
recommendation  to  track  stakeholder  requirements  as  part  of  the  standardisation  process  and  has  led  to  a 
proposed  C2SIM  Interoperability  Standardisation  and  Extension  Process. 

Furthermore,  various  organisations  have  different  goals  and  roadmaps  concerning  their  expectations  concerning 
the  Return  On  Investment  (ROI)  of  employing  C2SIM  interoperability  technologies.  For  example,  for  some 
stakeholders,  the  desired  goal  may  be  to  reduce  the  number  of  simulator  operators  required  to  hold  a  specific 
training  event.  This  is  an  example  of  a  cost-reduction  measure  for  a  sustaining  capability.  Other  stakeholders 
are  focused  on  future  capability  development  that  ultimately  implies  a  changing  how  military  operations  are 
conducted.  For  example  enhanced  automated  information  exchange  as  an  enabler  for  self-synchronisation  of  the 
battlefield  is  an  example  of  a  disruptive  technology  for  a  future  capability.  Figure  6-1  illustrates  the  differences 
and  implications  of  introducing  sustaining  and  disruptive  technologies  into  military  enterprise  activities  to 
establish  new  capabilities,  Concepts  of  Employment  (CONEMP)  and  Concepts  of  Operations  (CONOPS)1. 


1  A  CONOPS  or  CONEMP  generally  evolve  from  a  concept  and  is  a  description  of  how  a  set  of  capabilities  may  be  employed  to 
achieve  desired  objectives  or  end  state. 
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Figure  6-1:  Sustaining  versus  Disruptive  Technologies  [c/o  Pegasus  Research  and  Technologies], 


As  different  communities  and  Nations  work  toward  establishing  common  data  interoperability  standards,  it  is 
essential  that  differences  in  requirements  and  expectations  among  stakeholders  are  properly  recorded  and 
managed  such  that  an  appropriate  C2S1M  interoperability  standard  roadmap  that  is  suitable  to  all  parties  can  be 
constructed. 

6.2  COMBINED  STANDARD  SCENARIO  DEFINITION,  INITIALISATION  AND 
EXECUTION  (LL) 

Military  enterprise  activities  such  as  Command  Post  training  generally  require  scenario  definition, 
scenario  initialisation  and  scenario  execution. 

These  are  all  part  of  the  same  workflow  and  maintaining  separate  standards  for  military  scenario  definition  and 
for  military  scenario  execution  can  be  problematic.  Therefore  a  more  holistic  approach  to  military  scenario 
definition,  initialisation  and  execution  likely  would  be  more  practical  and  economical  to  implement. 

The  end-goal  of  stakeholders  is  to  conduct  military  enterprise  activities  such  as  training,  experimentation  or  the 
conduct  of  operations.  For  this,  they  require  a  functional,  representative  system-of-systems  that  includes  a 
C2S1M  federation.  Therefore,  it  is  important  to  place  the  focus  on  defining  the  means  to  simplify  the  definition, 
construction  and  execution  of  C2S1M  federations. 

Maintaining  separate  standards  for  scenario  definition  (i.e.  MSDL)  and  for  scenario  execution  (i.e.  C-BML) 
leads  to  significant  time  being  spent  in  defining  and  evolving  these  standards  and  also  in  applying  these 
standards  to  systems.  These  standards  should  be  merged  in  order  to  form  a  coherent,  unified  standard  for 
Military  Scenario  Initialisation  and  Execution. 
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Furthermore,  throughout  the  experimentation  programme,  experience  has  shown  that  specifying  schemas  for 
scenario  initialisation  and  execution  is  not  sufficient.  System  Design  Agreements  also  are  required  to  ensure  that 
the  C2S1M  federation  is  able  to  function  properly  and  support  the  goals  of  the  military  enterprise  activity. 
Therefore,  similar  to  the  DSEEP  approach  taken  by  the  simulation  community,  there  is  a  need  to  standardise  the 
process  by  which  C2S1M  federations  are  designed  and  executed.  This  is  further  discussed  in  Section  6.5. 

6.2.1  C2SIM  Core  (LI) 

The  SISO  MSDL/C-BML  specifications  are  sufficient  for  basic  operations  of  manoeuvre  warfare, 
but  insufficient  to  meet  the  broader  need  of  other  military  operations  and  support  functions. 

There  exists  a  core  set  of  BML  who/what/when/where  data  that  is  nearly  universal  for  military  orders  and  reports 
of  all  Nations  participating  in  MSG-085;  it  was  largely  captured  in  the  IBML09  schema  defined  for  MSG-048 
and  proved  its  utility  again  in  the  MSG-085  final  demonstration,  where  it  was  satisfactory  for  all  the  air/ground 
activities  desired  by  the  Operational  Sub-Group.  All  indications  were  that  it  would  have  been  satisfactory  for 
maritime  operations  as  well,  but  in  the  end  those  operations  were  not  carried  out.  Elowever,  beyond  this  core, 
a  wide  variety  of  data  elements  and  document  contexts  are  needed  for  the  full  breadth  of  BML.  Yet  creating  a 
single  massive  schema  leads  to  impractical  complexity.  Requirements  for  C2SIM  interoperation  vary  across 
services  and  Nations;  and  they  also  depend  on  the  themes  and  focus  areas  of  specific  training,  mission  rehearsal 
or  experimentation  events.  Thus,  an  approach  that  standardises  a  core  data  model  and  methods  for  extending  that 
model  to  needs  of  a  specific  instance  is  the  clear  path  forward. 

6.2.2  Need  to  Create  Unified  C2SIM  Standard  (LL) 

The  SISO  MSDL  and  C-BML  specifications  can  be  made  to  function  together,  but  new,  harmonised 
versions  are  required  for  most  effective  C2SIM  interoperation. 

The  SISO  MSDL  and  C-BML  standards  can  be  made  to  function  together,  although  this  requires  ignoring  some 
aspects  of  each.  However,  they  were  not  designed  to  work  together  so  their  approach  to  combining  initialisation 
and  tasking/reporting  is  not  harmonious.  A  new  generation  of  BML  standards  where  initialisation  and  tasking/ 
reporting  are  integrated  and  harmonised  is  needed  in  order  to  meet  future  BML  needs  in  the  coalition 
environment.  The  standard  could  be  packaged  either  as  one  unified  specification  or  in  two  parts,  initialisation 
and  tasking/situational  awareness.  However,  it  is  essential  that  the  package  be  fully  integrated,  which  in  turn  will 
require  an  integrated  SISO  Product  Development  Group  (PDG).  Participants  in  the  current  SISO  MSDL  and 
C-BML  PDGs  have  recognised  this  and  have  voted  unanimously  to  reorganise  as  a  single  PDG  before  the  end  of 
2014. 


6.2.3  Standardising  Core  Data  Model  versus  Schema  (LI) 

It  is  more  effective  to  standardise  a  core  data  model  and  procedures  to  extend  it,  than  to  standardise  a 
schema. 

It  is  reasonable  to  infer  that  MSG-085  implementers  of  C-BML  found  the  SISO  C-BML  Phase  1  “Full  Schema” 
to  be  impractical  to  implement.  Several  MSG-085  implementers  so  stated  and  none  of  them  chose  to  use  the 
“Full  Schema”,  even  though  it  was  possible  to  interoperate  it  with  other  schemata  in  use,  using  the  schema- 
translating  server  capability  that  was  available.  Yet,  despite  its  complexity,  it  is  clear  that  the  “Full  Schema”  is 
inadequate  to  provide  tasking  and  situational  awareness  for  many  aspects  of  military  operations,  for  example 
logistics,  engineering,  medical  services,  and  telecommunications.  Another  group  developing  interoperability 
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capabilities  for  NATO,  the  Multi-lateral  Interoperability  Programme  (MIP)  was  faced  with  a  similar  explosion  of 
complexity.  MIP  has  explored  an  alternative  which  they  have  shown  to  be  effective:  create  a  core  data  model, 
provide  tools  and  standard  methods  to  expand  that  model  as  needed,  and  also  provide  tools  to  generate  an 
instance  schema  on  ad-hoc  basis.  The  MSG-085  “2RS”  CIG  explored  this  approach  in  depth  and  has  developed 
a  convincing  demonstration  of  its  utility. 

6.2.4  C2SIM  Standard  Extensibility  (LI) 

The  “one-size-fits-all”  approach  is  not  viable  for  building  C2SIM  interoperability  standards. 

Differences  across  services,  Nations  and  other  communities  make  it  impractical  to  try  and  develop  a  standard 
that  meets  all  requirements  from  all  stakeholders  for  all  activities.  Therefore,  C2SIM  interoperability  standards 
must  provide  the  “greatest  common  denominator”  AND  allow  for  rapid  and  easy  extension  of  standards  products 
as  required  to  meet  specific  C2SIM  federation  requirements. 

Therefore,  a  data  interoperability  approach  that  defines  a  common  core  that  is  extensible  has  many  advantages 
over  an  approach  that  seeks  to  establish  a  universal  standard  that  can  meet  the  requirements  of  all  communities. 

6.2.5  C2LG  Tasking  Grammar  (LL) 

The  C2LG  Tasking  Grammar  provides  a  useful  basis  for  unambiguous  tasking  and  situational  awareness 
in  C2SIM  interoperation  that  can  be  extended  to  a  full  semantic  capability. 

The  MSG-085  Technical  Sub-Group  made  a  study  of  the  role  of  grammar  in  tasking.  Grammar  defines  structure 
and  syntax,  but  does  not  include  the  semantics  that  determine  whether  expressions  “make  sense”  or  not. 
For  example,  using  SISO  C-BML  it  is  possible  to  task  a  tank  to  fly.  The  C2LG  was  developed  to  be,  in  the 
words  of  Albert  Einstein,  “as  simple  as  possible,  but  no  simpler  than  that”  as  a  means  of  representing  C2 
information  that  is  used  by  automated  processes.  It  limits  tasking  to  a  set  of  very  simple  structures  and  introduces 
lexicality  and  thematic  roles  that  constrain  statements  to  those  that  make  sense.  If  fully  implemented,  it  will  not 
allow  an  order  for  a  tank  to  fly.  Future  BML  systems  can  be  expected  to  feature  an  expanded  role  for  semantics, 
for  example:  including  “frames”  that  consider  whether  the  “what”  action  is  consistent  with  the  “where”; 
including  “types”  for  objects  that  restrict  conditions  under  which  they  are  referenced;  and  considering  the 
capabilities  of  each  “who”  when  they  are  tasked.  Such  future  systems  will,  as  a  first  step,  include  C2LG  or  a 
similar  grammar  to  deal  with  frames  and  types  and,  as  a  second  step,  an  ontology  to  capture  the  capabilities.  As  a 
result,  automated  systems  will  issue  taskings  that  make  sense,  just  as  human  warfighters  orders  couch  their  tasks 
in  the  light  of  the  constraints  of  the  real  world. 

6.2. 5.1  Pragmatic  Approach  (LL) 

The  successes  achieved  during  the  MSG-085  demonstrations  and  experiments  are  largely  due  to  the  pragmatic 
approach  to  grammar  that  was  employed.  Example  expressions  were  been  derived  from  the  different  grammar 
proposals  in  order  to  determine  the  content  these  expressions  conveyed.  Then,  a  family  of  XML  schemata  were 
developed.  Although  some  variations  existed  among  these  schemata,  collectively  they  were  able  to  convey  the 
relevant  content  required  for  the  various  demonstrations  and  experiments.  Reference  [19]  is  an  internal 
document  that  has  been  generated  by  MSG-085  and  includes  sets  of  BML  expressions  for  ground  operations, 
air  operations,  and  maritime  operations  that  were  used  in  MSG-085’s  experiments  and  demonstrations 
(see  Chapter  5).  Information  exchange  using  BML  messages  during  some  of  these  events  entailed  the  use  of 
multiple  BML  web  services  (e.g.  GMU  and  the  FKIE). 
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One  problem  that  was  encountered  was  that  some  simulation  systems  require  that  certain  task  assignments 
include  specific  geographical  features  in  order  to  interpret  assigned  task  as  intended.  At  times,  the  required 
geographical  feature  data  is  not  part  of  the  BML  expression.  For  example,  an  attack2  task  is  defined  as: 
“to  conduct  a  type  of  offensive  action  characterized  by  coordinated  employment  of  firepower  and  manoeuvre  to 
close  with  and  destroy  or  capture  the  enemy.”  However  to  execute  an  attack  task,  some  simulation  systems  do 
not  require  to  specify  the  enemy  but  rather  require  a  geographic  point  as  a  target.  The  solution  to  this  problem 
that  was  adopted  was  to  provide  the  location  of  the  enemy  as  a  geographical  target  point.  This  proved  sufficient 
as  long  as  the  enemy  did  not  move  substantially  during  the  period  of  time  between  the  issue  of  the  order  to  attack 
and  the  execution  of  that  order.  In  some  instances,  additional  geographic  information  was  required  for  attack 
tasks.  For  example,  the  French  simulation  system  require  coordination  lines,  namely  left  and  right  border  of  the 
attack  corridor,  to  execute  attack  tasks.  This  problem  illustrates  that  although  the  semantic  grounding  of  BML  on 
the  JC3IEDM  has  proven  to  be  successful,  there  are  limits  when  tasks  implemented  in  a  simulation  system  do 
not  agree  with  the  corresponding  definition  of  the  same  task  in  JC31EDM.  Also,  in  some  cases  the  JC31EDM 
does  not  fully  cover  Nation-specific  or  service-specific  doctrine  that  may  be  implemented  in  simulation  systems. 

6.2.6  Advanced  Grammar  Approaches  (LI) 

The  BML  Grammar  must  meet  the  needs  of  a  wide  range  of  requirements  with  varying  level  of 
complexity. 

As  mentioned  in  Section  6.1,  there  are  significant  differences  in  requirements  and  expectations  across 
stakeholders  from  different  communities  and  Nations.  Some  Nations  require  only  a  simplified  grammar  to 
capture  the  structure  and  syntax  of  structured  data  messages  in  support  of  sustaining  capabilities. 

A  grammar  typically  defines  structure  and  syntax  and  does  not  include  the  semantics  that  determine  whether 
expressions  “make  sense”  or  not.  Advanced  grammar  approaches  may  introduce  the  lexicality  or  thematic  roles 
that  introduce  business  rules  into  the  grammar.  This  approach  can  be  useful  for  some  future  capability 
development  that  will  involve  intelligent  systems  or  automated  systems  that  will  process  complex  messages, 
some  of  which  may  involve  natural  language  type  expressions.  However,  it  cannot  be  assumed  that  this  is  the 
general  case.  Therefore,  the  grammar  might  be  restricted  to  a  simple  set  of  production  rules  that  specify  only 
structure  and  syntax.  However,  a  mechanism  is  required  to  specify  business  rules  such  that  they  can  be 
communicated  independently  of  the  messages  and/or  utilized  as  part  of  advanced  grammar  approaches. 


6.2.6.1  Production  Rules  versus  Business  Rules  (LI) 

It  is  important  to  separate  the  production  rules  (i.e.  grammar)  from  the  business  rules.  The  grammar  is  common 
to  all  users  of  the  standards  whereas  the  Business  Rules  may  depend  on  national  doctrine  or  specific  rules  of 
engagement.  For  illustrative  purposes,  production  rules  should  allow  for  the  construction  of  the  following 
statement: 


(1) 


UNIT_1  tasks  UNIT_2  to  MOVE  from  LOCATION_l  to  LOCATION_2  at  June  Tl. 


However,  it  then  becomes  important  to  be  able  to  define  business  rules  that  complement  the  production  rules. 
Examples  of  possible  business  rules  are: 


2  As  per  the  JC3IEDM  3.1.4  definition. 
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(2) 


For  MOVE  with  NUM_OF_LOCATION  =  2;  LOCATION_l  cannot _be_equal Jo  LOCATION_2. 

UNIT_1  is  not subordinate  _o/UNIT_2. 

T1  is  equal  or  greater  than  OPERATIONAL_TIME_STAMP. 


To  support  complex  grammar  approaches,  it  therefore  is  necessary  to  specify  business  rules  in  a  manner  that 
allows  for  their  translation  as  complex  production  rules,  such  as  those  specified  by  Lexical  Functional  Grammar 
approaches.  Toward  this  goal,  business  rules  may  be  defined  using  one  of  the  so-called  rules  languages  such  as 
the  Rules  Interchange  Format  (RIF)  family  of  languages  [26].  The  use  of  RIF  languages  also  is  consistent  with 
an  ontology-based  approach  discussed  further  in  Section  6.6.1. 


6.2. 6.2  Lexical  Functional  Grammar  Approaches  (LI) 

Lexical  Functional  Grammar  (LFG)  approaches  for  C2SIM  interoperability  languages  such  as  C2LG  and  OIEG 
have  been  proposed  for  consideration  by  standardization  bodies  and  therefore  have  been  considered  during  the 
MSG-085  Technical  Activity.  However,  the  C2LG  approach  is  much  simplified  compared  to  classical  LFG 
languages  since,  for  example,  it  does  not  include  f-structures  or  a-structures.  The  most  important  feature  in 
C2LG  that  has  been  borrowed  from  the  LFG  approach  is  the  concept  of  lexicality.  This  offers  in  a  simple  way 
LFG’s  principles  of  completeness  and  coherence.  Otherwise,  the  grammar  would  allow  orders  like: 


(3) 


UNIT  A1  tasks  UNIT  A2  to  ADVANCE/oi  UNIT  B  at  CONTROL  POINTBRA VO  before Jime  ALHPA. 


This  expression  has  two  problems: 

1)  It  specifies  “for  UNIT  B”,  that  is  known  as  an  affectedWho  in  C2LG,  although  “advance”  does  not 
requires  it;  and 

2)  It  specifies  a  location,  whereas  an  ADVANCE  task  should  specify  a  destination  or  a  direction. 

LFG  approaches  are  especially  useful  for  capturing  natural  language  aspects  of  military  information.  Several 
use-cases  where  LFG-type  languages  would  satisfy  C2SIM  interoperation  requirements  have  been  identified. 
These  include  “Intelligent  Chat”  capabilities  and  “Voice  Command- to-C2  system-translation”.  However,  for  the 
majority  of  C2S1M  requirements  identified  during  the  MSG-085  Technical  Activity,  LFG-type  grammars 
generally  are  not  required.  Some  stakeholders  have  articulated  the  need  for  a  “simple”  grammar  that  might  be 
extended  to  include  user-specific  business  rules. 

The  use  of  OIEG  as  a  means  for  representing  Commander’s  Intent  is  still  an  area  of  research,  but  may  prove 
useful  in  the  future  in  bridging  the  gap  between  a  human  commander  and  a  machine  interface. 


6.3  NEED  TO  FORMALLY  MANAGE  STANDARD  PRODUCTS  (LL) 

6.3.1  Maintain  Logical  Data  Model,  Generate  Derived  Products  (LL) 

Don’t  build  the  model  as  an  XML  schema;  build  a  logical  data  model  and  generate  XML  schemas. 

C2SIM  interoperability  often  is  achieved  through  the  sharing  of  XML  schema  that  define  the  structure  and 
content  of  the  information  to  be  shared.  Therefore  it  is  tempting  to  standardize  sets  of  XML  schema.  However, 
for  all  but  the  simplest  of  data  models,  this  has  proven  to  be  problematic  since  it  rapidly  becomes  difficult  to 
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evolve  schemas  to  satisfy  new  requirements.  Other  standardization  organizations  such  as  the  M1P  already  have 
put  into  place  methods  and  tools  to  define  and  evolve  a  logical  data  model  using  UML. 

Using  a  Model-Driven  Architecture  (MDA)  approach,  it  then  becomes  possible  to  generate  derived  products 
such  as  XML  schemas.  Furthermore,  this  approach  allows  for  the  parallel  production  of  other  equivalent  derived 
products  such  as  HLA-FOM  modules  or  OWL  ontology  modules.  Beyond  the  advantage  of  saving  time  and 
ensuring  a  coherent  set  of  derived  standard  products,  this  approach  also  avoids  human-error  that  may  occur  when 
manually  modifying  XML  schema. 

6.3.2  Standardisation  of  the  Process  and  Production  Chain  (LL) 

Utilise  a  standardised  approach  and  process  and  publicly  available  tools  to  develop  and  maintain  the 
logical  data  model  and  to  generate  derived  products  such  as  XML  schemas,  HLA  FOMs  and  JSON 
objects. 

Toward  the  goal  of  employing  a  MDA  based  on  an  extensible  core  logical  data  model,  it  becomes  important  to 
define  a  process  by  which  stakeholder  requirements  can  be  collected,  managed  and  effectively  traced  to  the 
derived  standard  products.  The  process  should  include  important  steps  such  as  verification  of  requirements  and 
also  validation  of  the  derived  products.  Standardising  the  process  will  facilitate  the  extension  process  such  that 
communities  can  define  and  build  community  specific  extensions  in  the  same  way. 

Along  the  same  lines,  a  publicly  available  toolset  that  is  consistent  with  the  standardized  approach  can  greatly 
facilitate  the  creation  of  community  extensions.  Moreover,  there  are  additional  benefits  to  developing  a  common 
production  chain  for  use  by  the  standardization  and  by  the  solution  providers.  For  instance,  community  specific 
extensions  can  be  proposed  as  subsequent  use  by  other  communities  and/or  as  candidates  for  standardization. 


6.4  C2SIM  INFRASTRUCTURE  LESSONS  LEARNED  (LL) 

6.4.1  Supportability  of  Coalition  C2SIM  Interoperation  (LL) 

Technical  teams  from  coalition  partners  are  able  to  work  quickly  to  assemble  a  system-of-systems  with  C2 
systems  and  simulation  systems  from  each  partner,  based  on  clear  specifications  for  data  sharing. 

The  final  demonstration  of  MSG-085  involved  ten  Nations,  using  a  total  of  six  national  C2  systems  and  five 
national  simulations.  Some  of  these  had  been  adapted  to  MSDL/C-BML  as  long  ago  as  2009,  while  others  were 
adapted  in  2013,  but  all  underwent  hardening  in  2013  that  increased  their  Technology  Readiness  Level  (TRL)  to 
an  estimated  level  five  or  better.  While  the  various  participating  Nations  began  MSG-085  with  different  levels  of 
experience  with  regard  to  distributed,  networked  operations,  everyone  was  able  to  adapt  the  available 
technologies  to  their  national  systems,  work  as  a  team  to  test  their  systems,  correct  any  problems,  and  bring  their 
C2  and/or  simulation  systems  into  the  system-of-systems  assembled  for  the  MSG-085  final  demonstration. 
This  experience  holds  great  promise  for  a  time  in  the  not-so-distant  future  when  C2S1M  interoperation  becomes 
routine  to  the  point  where  the  national  participants  in  a  coalition  organisation  can  begin  interoperating  over  a 
common  network  immediately  upon  receiving  notice  of  a  mission. 

6.4.2  Distributed  Use  of  Coalition  C2SIM  Interoperation  (LL) 

It  is  practical  to  assemble  and  use  a  C2SIM  system-of-systems  over  a  network  that  has  moderate 
performance;  co-location  of  participants  is  not  required. 
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Most  of  the  development  and  testing  required  by  MSG-085  was  accomplished  over  the  Internet,  using  Virtual 
Private  Network  (VPN)  technology  for  privacy.  No  classified  data  or  capabilities  were  involved.  In  addition  to 
the  C2SIM  interoperation  traffic,  it  proved  quite  practical  to  use  Internet  teleconferencing  tools  within  the  VPN 
to  coordinate  ongoing  activities.  For  the  final  demonstration,  national  systems  of  Great  Britain  and  Spain  were 
operated  from  Famborough,  Great  Britain,  and  Madrid,  Spain,  respectively.  The  network  capacity  required  was 
not  large,  despite  a  scenario  that  reflected  realistic  operations  on  the  part  of  a  multi-national  Brigade  consisting 
of  four  Battalion-size  elements.  Moreover,  because  of  restrictions  on  use  of  the  Internet  at  the  demonstration 
facility,  the  Internet  links  used  came  through  cellular  telephone,  not  through  high-capacity  “land  lines”. 

6.4.3  Combining  Various  Versions  of  MSDL/C-BML  (LI) 

There  is  a  need  to  be  able  to  work  simultaneously  with  various  versions  of  C2SIM  interoperation 
standards. 

Dealing  with  multiple  versions  of  the  BML  specification  is  a  practical  necessity.  This  is  because  the  schema  of 
choice  for  each  participating  C2  and  simulation  system  was  selected  and  implemented,  at  the  time  that  system 
first  joined  a  coalition  environment;  while  some  updates  to  interfaces  of  individual  systems  may  occur, 
the  national  proponents  generally  are  not  willing  to  invest  resources  in  each  major  schema  revision. 
The  discrepancy  among  schema  formats  can  be  dealt  with  by  a  translating  server,  which  parses  order/ 
request/report  XML  input  and  converts  it  to  a  common  internal  data  model,  then  produces  equivalent  XML 
documents  under  the  schemas  used  by  other  participating  systems.  This  approach  is  applicable  wherever  the 
semantics  of  the  schemata  are  aligned,  regardless  of  the  syntax  employed;  it  was  used  in  the  MSG-085  final 
demonstration  with  success. 


6.5  NEED  A  C2SIM  DSEEP  OVERLAY  (LI) 

6.5.1  A  Standardised  Process  for  the  Use  of  MSDL/C-BML  for  Building  C2SIM  Federations 

Additional  coalition-wide  best  practices  and  data  exchange  agreements  are  necessary  to  support  advanced 
interoperability  within  a  coalition  of  C2  and  simulation  systems. 

Data  exchange  agreements  are  necessary  to  ensure  understanding  of  even  simple  C-BML  based  orders  such  as 
movement  orders  that  could  potentially  include  movement  routing  information  constructed  from  a  variety  of 
waypoint-based,  referencing  based,  or  start  and  end-point  based  data  elements.  To  this  end,  existing  simulation- 
based  process  standards  such  as  the  Distributed  System  Engineering  and  Execution  Process  (DSEEP)  and 
associated  federation  agreement  activities  should  be  included  as  part  of  any  standards-based  interoperability 
approach. 

6.5.2  Stakeholders  Include  Both  C2  and  Simulation  Communities  (LI) 

It  is  important  to  include  stakeholders  from  both  the  simulation  and  C2  system  user  communities  in  the 
process  of  defining  the  C2SIM  standards  and  adapting  them  for  use  in  a  specific  event. 

To  engineer  and  execute  a  C2SIM  federation,  we  should  recognize  that  the  process  involves  two  communities  of 
stakeholders:  C2  stakeholders  and  simulation  stakeholders.  The  involvement  of  both  communities  throughout  the 
DSEEP  process  is  mandatory  to  achieve  the  end-users  needs. 

The  solution  is  to  describe  in  the  C2SIM  DSEEP  overlay  the  responsibilities  of  each  community  and  their 
interactions.  The  C2SIM  DSEEP  overlay  has  been  drafted  on  this  topic. 
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6.5.3  End-Users’  Perception  of  Federation  Execution  (LI) 

Ensure  the  operational  relevance  of  the  information  to  be  exchanged. 

During  the  federation  design,  stakeholders  should  ensure  that  the  operational  situations  and  orders  to  be 
displayed  on  the  end-users’  systems  are  relevant  to  the  purposes  of  the  specific  activities  to  be  conducted. 
Therefore,  the  messages  and  data  exchanged  during  federation  execution  must  contain  the  necessary  and 
sufficient  information  to  support  these  activities. 

The  key  elements  of  interest  have  been  defined  in  the  C2S1M  DSEEP  Overlay.  These  elements  are  extracted 
from  the  lessons  learned  of  the  MSG-085  experimentations,  and  are  described  along  with  proposed  solutions. 
They  are: 

•  For  report  message  processing: 

•  Level  of  detail  of  information  required  by  end-user  and/or  C2  system  (e.g.  training  a  Brigade  EIQ 

requires  aggregated  observation  message,  while  training  a  Battalion  EIQ  requires  single  vehicle 

observation  messages); 

•  Ground  truth  vs.  perceived  truth  (e.g.  ground  truth  is  not  relevant  for  training); 

•  Simulation  information  filtering  (e.g.  C2  systems  may  only  need  a  sub-set  of  information  provided 
by  simulation,  depending  on  their  role  and  capabilities);  and 

•  Information  overload  (e.g.  message  rates  from  simulations  can  overload  C2). 

•  For  order/requests  message  processing: 

•  Orders/requests  may  call  for  behavior  not  present  in  simulation  (e.g.  unit’s  type  or  level  not  handled 
by  simulation,  task  verb  not  handled  by  simulation);  and 

•  The  doctrine  according  to  which  the  C2  systems  generate  orders/requests  can  differ  from  the 
doctrine  that  is  implemented  in  the  simulation  systems. 

6.5.4  C2SIM  Reference  Architecture,  Services  (LI) 

A  C2SIM  reference  architecture  should  be  defined  to  facilitate  C2SIM  federation  design. 

Various  C2SIM  infrastructures  exist  (like  FK1E  C-BML  server,  SBML  GMU  server,  CBMS  VMASC  server) 
and  a  member  application  usually  functions  with  only  one  specific  infrastructure.  It  is  likely  that  federation 
design  will  lead  to  the  use  of  several  C2SIM  infrastructures.  To  facilitate  this  integration,  a  reference  architecture 
should  be  defined  or  standardised  along  with  the  definition  of  services  (mandatory  or  optional  services). 

The  services  should  also  implement  requirements  that  are  not  today  addressed,  but  that  are  important  for  an 
operational  use  of  the  federation  like  late  joining  federates,  save  and  restore  points,  or  time  management 
(see  next  section). 

This  implies  a  need  to: 

•  Design  a  C2SfM  reference  architecture  with  the  services  it  should  contain  (mandatory  or  optional 
services);  and 

•  Adapt  the  C2SfM  DSEEP  overlay  to  explain  when  and  how  to  use  those  services. 


STO-TR-MSG-085 


6-9 


LESSONS  IDENTIFIED  AND  LESSONS  LEARNED 


organization 


6.5.5  Time  Management  (LI) 

C2SIM  federation  design  must  account  for  inherent  differences  in  the  time  management  mechanisms 
between  simulation  and  C2  systems. 

What  distinguishes  simulation  systems  from  most  other  type  of  systems  is  the  ability  to  and  necessity  to 
manipulate  time.  Usually,  C2  systems  are  locked  to  the  current  real-world  time,  whereas  simulations  manipulate 
time  as  a  variable  -  and  this  may  results  in  some  unprocessed  messages  or  errors  inside  the  C2  system  during  the 
federation  execution.  For  example  during  C1G  Land  Operation  experimentation,  the  French  SIR  system  popped 
up  a  dialog  warning  the  operator  that  a  message  hasn’t  been  processed  because  of  a  DTG  (Date  Time  Group)  in 
the  future. 

Currently,  this  issue  has  been  described  in  the  C2S1M  DSEEP  overlay,  which  also  includes  several  technical 
solutions  at  different  time  frames.  For  the  long  time-frame,  time  management  services  shoidd  be  defined  and 
standardised  in  a  Reference  C2S1M  federation,  and  implemented  by  infrastuctures,  C2  and  simulations  systems. 


6.6  FUTURE  REQUIREMENTS  FOR  C2SIM  INTEROPERATION  (LI) 

6.6.1  Ontology  and  Business  Rules  (LI) 

Need  to  develop  a  BML  Ontology  and  finalise  an  approach  for  specifying  Business  Rules. 

The  S1SO  Product  Nomination  for  C-BML  calls  for  the  development  of  a  C-BML  ontology.  Until  recently,  little 
work  has  been  done  in  this  area.  Although  the  use  of  ontology  remains  primarily  a  subject  of  research,  the  future 
C2S1M  interoperability  standards  should  support  the  optional  use  of  ontological  means  in  support  of  advanced 
use-cases.  The  MSG-085  Technical  Group  has  defined  two  families  of  use-cases  for  a  C-BML  ontology: 

1)  The  construction  and/or  validation  of  C-BML  messages;  and 

2)  The  specification  of  constraints,  triggers  and  criteria  required  for  task  execution. 

6.6.1. 1  Validation  and  Construction  (LI) 

When  constructing  C-BML  messages,  the  grammar  will  ensure  that  the  message  structure  is  well-formed. 
However,  additional  validation  may  be  required  to  ensure  that  the  message  is  consistent  with  the  national 
doctrine,  procedures  and/or  rules  of  engagement  for  a  specific  operation.  This  additional  validation  can  be 
implemented  using  sets  of  business  rules  that  can  be  associated  with  ontologies.  At  the  information-producer 
side,  interfaces  called  Smart  GUIs  can  facilitate  the  construction  of  valid  messages  by  guiding  the  user  through 
context-sensitive  menus  and  forms.  Alternately,  at  the  information-consumer  side,  other  sets  of  business  rules 
can  validate  that  the  message  that  has  been  received  is  consistent  with  the  doctrine,  procedures  and  rules  of 
engagement  of  the  consuming  system. 

6.6.1.2  Message  Correction  (LI) 

In  some  instances,  a  message  may  be  deemed  invalid.  Therefore  it  may  be  rejected  or  it  may  be  possible  to 
correct  the  message  based  on  knowledge  of  which  business  rules  failed.  For  example  for  certain  C2  systems, 
a  FIX  task  may  require  a  start  point  and  a  vector  -  but  it  is  possible  that  only  two  points  are  provided,  consistent 
with  the  manner  in  which  other  C2  systems  specify  FIX  task  information.  A  “Message  Correction”  mechanism 
could  allow  for  an  automatic  conversion  of  two  points  into  one  point  and  a  vector  and  also  to  convert  a  start 
point  and  vector  into  two  points,  as  required. 
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6.6.1.3  Message  Conversion  (LI) 

In  the  case  of  a  Task,  it  may  be  possible  to  use  the  explicit  information  contained  in  business  rules  that  have  been 
established  for  a  specific  national  force  (e.g.  Norway)  and  specifically  convert  the  task  for  use  by  another  force 
(e.g.  France)  while  taking  full  consideration  of  both  the  military  capabilities  of  both  forces  and  their  difference  in 
national  warfighting  doctrine. 

6.6.1.4  Specifying  Task  Qualifiers,  Triggers  and  other  Criteria  (LI) 

Task  start  and  end  times  are  specified  as  absolute  times  or  relative  times.  Relative  times  reference  the  start/end 
times  of  other  tasks.  However  in  some  cases,  the  start  or  end  of  a  given  task  may  depend  on  a  set  of  criteria  that 
determine  when  the  task  can  commence  or  when  it  has  been  completed.  These  task  start/end  criteria  can  be 
associated  with  set  of  conditions  that  are  expressed  as  business  rules.  For  example,  a  SEIZE  task  may  be 
considered  completed  based  on  criteria  that  indicate  the  number  and  operational  status  of  the  remaining  enemy 
units  above  a  certain  troop  size. 

Similarly,  task  qualifiers  such  as  “HASTY’  ATTACK  can  be  expressed  in  terms  of  a  set  of  rules  that  define 
when  specific  HASTY  ATTACK  conditions  have  been  satisfied. 

Finally,  rules  of  engagement  could  be  specified  as  sets  of  business  rules,  such  as  shown  in  Table  6-1. 

Table  6-1:  Example  Rules  of  Engagement. 


I.  UNIT  may  employ  DEADLY_  FORCE,  If: 

A  UNIT  has  been  FIRED  UPON; 

B  {ARMED  ELEMENT  or  MOB'  threaten  HUMAN_LIFE; 

C.  ELEMENT  has  Remonstrated  HOSTILEINTENT ; 

1.  ELEMENT  has  Remonstrated  HOSTILEINTENT,  If: 
i.  WEAPONS  are  PRESENT; 
ii  WEAPONS  are  AIMED; 

II  UNATTENDED  MEANS_OF  FORCE  arejiot  AUTHORIZED; 

UNATTENDED  ME ANS_OF  FORCE  =  {BARBED  WIRE,  MINE,  BOOBY  TRAP,  TRIP  GUN} 


6.7  VALIDATION  OF  OPERATIONAL  RELEVANCE  (LL) 

6.7.1  C2-to-C2  Exchanges  (LL) 

It  was  identified  that  a  simple  C2-to-C2  interoperability  solution  was  needed  during  experimentations, 
without  having  to  implement  and  deploy  regular  C2-to-C2  gateways. 

The  solution  to  this  issue  has  been  to  develop  a  C-BML  message  header,  adding  new  information  to  C-BML 
messages  like  the  sender  and  the  recipient  units.  This  solution  has  been  validated  through  experimentation. 
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6.7.2  Logistic  Domain  (LL) 

Up-to-date  information  about  unit  consumables,  equipment  and  personnel  is  important  in  military 
situation  assessment  and  planning.  The  MSDL  and  C-BML  schemas  need  to  be  extended  in  order  to 
better  support  this  capability. 

The  NATO  Stock  Number  (NSN)  was  used  to  identify  equipment  across  all  NATO  Nations,  including  different 
simulation  and  C2  systems.  The  MSDL  schema  was  adjusted  to  allow  describing  the  initial  logistical  situation. 
The  BML  schema  was  also  extended  to  report  about  changes  in  the  logistic  situation,  e.g.  when  ammunition  is 
consumed. 

6.7.3  Acknowledgments  (LL) 

Acknowledgement  of  orders  by  receiving  systems  is  necessary  in  different  situations. 

The  first  case  is  when  an  order  is  given  to  the  simulation  system.  The  simulation  system  can  send  an 
acknowledgment  if  it  is  able  to  execute  the  order  or  it  can  respond  with  an  abort  and  give  a  reason.  Reasons 
could  be: 

1)  The  order  does  not  comply  to  the  requirements  by  the  simulation  system;  and 

2)  The  order  is  not  formatted  correctly. 

For  example,  the  simulation  may  receive  an  order  that  specifies  unsupported  missions  or  that  contains  erroneous 
or  missing  geographic  features  -  or  the  simulation  may  be  missing  equipment  required  to  execute  a  specific 
action.  This  led  to  a  faster  creation  of  an  executable  order.  Acknowledgment  can  also  be  used  for  C2  to  C2 
communication  to  inform  the  superior  unit  the  operator  has  read  or  committed  to  the  order. 


6.8  NEED  FOR  INCREASED  STAKEHOLDER  INVOLVEMENT  (LI) 

6.8.1  Challenges  to  Engage  Industry  (LI) 

Industry  involvement  is  required  to  ensure  the  development  of  usable  C2SIM  interoperability  standards 
products. 

Although  efforts  have  been  made  to  engage  industry  through  S1SO  and  initiatives  such  as  the  C-BML  Industry 
Task  Team  (CITT)  this  after  some  initial  success  lapsed  due  to  insufficient  resources  to  maintain  the  effort. 
The  establishment  of  a  merged  C-BML/MSDL  PDG  within  S1SO  and  a  proposed  follow-on  TA  to  NMSG-085 
should  reenergise  industry  engagement.  A  C-BML/MSDL/C2S1M  certification  process  should  be  considered  as 
another  mechanism  for  industry  engagement.  For  the  latter  to  be  taken  forward  it  requires  NATO/Govemment/ 
Industry  sponsorship. 

6.8.2  Employment  of  C2SIM  Interoperability  Technologies  (LI) 

Need  to  increase  the  trial  use  of  C2SIM  interoperability  technologies  to  include  more  stakeholders. 

MSG-085  has  demonstrated  that  C2SIM  is  ready  to  begin  the  process  of  incorporation  into  national  and  NATO 
military  systems.  However,  this  does  not  mean  that  all  systems  intended  for  operational  use  should  be  converted 
immediately  to  have  a  C2SIM  capability.  The  next  step  should  be  trial  use  of  C2SIM  in  operational  systems  in 
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carefully  controlled  environments,  so  that  both  operational  military  and  technology  suppliers  learn  how  best  to 
deploy  this  new  capability.  On  the  operational  side,  this  process  must  be  followed  by  introduction  of  appropriate 
doctrine.  On  the  technical  side,  the  C2S1M  capability  needs  to  be  both  hardened  and  broadened.  This  can  be 
accomplished  in  the  context  of  a  follow-on  TA  that  works  with  early  adopters  in  the  military  community. 

6.8.3  Need  for  NATO  Lecture  Series  (LL) 

Inform  the  community  on  the  use  and  benefits  of  C2SIM  products. 

As  part  of  the  wider  dissemination  of  both  the  operational  benefits  and  technical  composition  of  the  current 
C2S1M  products  a  NATO  Lecture  Series  should  be  run  and  a  TAP  has  been  proposed  by  GBR  and  provisionally 
supported  by  both  the  FRA  and  the  USA  to  establish  this  TA. 

6.9  REQUIREMENT  FOR  A  FUNDED  DEVELOPMENT  ACTIVITY  (LI) 

Effective  development  of  C2SIM  standards  requires  a  funded  technical  activity  to  develop  and  validate 
the  technical  approach  before  it  is  codified  as  a  standard. 

Considerable  frustration  during  MSG-048  came  from  the  assumption  that  S1SO  would  develop  standards  and 
MSG-048  would  use  them.  When  S1SO  did  not  produce  a  standard  in  time  for  this  approach  to  work,  MSG-048 
adopted  for  experimentation  a  schema  that  had  been  produced  by  its  national  technical  members.  This  proved  to 
be  a  successful  approach  and  it  was  used  in  the  MSG-048  final  experimentation,  validating  its  utility  in  that 
environment.  A  schema  derived  from  the  final  ones  used  by  MSG-048  ultimately  was  adopted  as  a  significant 
part  of  the  S1SO  C-BML  Phase  1  draft  standard. 

At  the  outset  of  MSG-085,  some  confusion  remained  on  the  appropriate  sequence  of  activities  in  standards 
development.  During  MSG-085  it  became  clear  that  S1SO  lacks  both  the  resources  to  develop  coalition  BML 
standards  and  a  means  of  validating  those  standards  in  use,  whereas  MSG-085  had  both  and  as  part  of  its 
activities  has  developed  a  new  approach  (see  Lessons  Learned  1  and  5  for  details)  that  clearly  offers  a  better 
technical  approach  for  the  future.  As  a  result,  a  new  picture  of  the  appropriate  relationship  between  the  NATO 
MSG  and  SISO  for  coalition  standards  has  emerged:  technical  activities  conducted  by  the  MSG  should  develop 
usable  alternatives  and  validate  their  utility  by  application  in  the  target  environment;  the  resulting  specifications 
should  be  provided  to  SISO  for  codification  into  standards  documents.  This  cycle  has  been  demonstrated  to  be 
effective  by  other  successful  standards  bodies,  such  as  the  Internet  Engineering  Task  Force,  and  represents  the 
best  path  forward  for  C2S1M  interoperability  standards: 

•  Technical  providers  develop  an  approach; 

•  Appropriate  users  apply  the  approach  to  validate  it;  and 

•  A  standards  body  then  codifies  the  approach. 
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Chapter  7  -  CONCLUSIONS  AND  RECOMMENDATIONS 

The  MSG-085  TA  has  made  significant  progress  in  advancing  the  standardisation  of  C2SIM  interoperation 
toward  the  goal  of  providing  a  capability  that  can  improve  the  decision-making  and  training  in  coalition 
military  operations.  Starting  with  a  concept,  the  community  involved  in  C-BML/MSDL,  both  in  NATO  and 
S1SO,  has  achieved  continued  progress  toward  the  goal  that,  in  the  not  too  distant  future,  military  coalitions  will 
be  able  to  come  together  and  benefit  from  interoperating  C2  and  simulation  systems  across  all  Nations 
participating. 

While  commendable  progress  has  been  made  toward  the  goal  of  establishing  a  set  of  standardised,  technically 
mature  C2S1M  interoperability  products,  much  remains  to  be  accomplished.  The  feasibility  of  C2S1M  was 
demonstrated  by  MSG-048  and  the  utility  of  C2S1M  interoperability  has  been  demonstrated  by  MSG-085. 
What  remains  is  to  engage  the  operational  military  community  in  the  various  NATO  Nations  and  provide  them 
compelling  evidence,  in  the  fonn  of  well-supported  training  events  that  incorporate  mission  planning  and 
mission  rehearsal,  that  the  products  that  enable  C2S1M  interoperability  should  be  an  integral  part  of  NATO  and 
national  C2  systems. 

In  addition  to  work  with  the  operational  community,  there  is  much  technical  effort  remaining  to  improve  C2S1M 
interoperability.  S1SO  C2S1M  PDG  needs  to  include  a  next  generation  of  both  MSDL  and  C-BML  to  facilitate 
both  their  working  together  and  the  scope  of  the  interoperability  they  are  able  to  achieve.  MSDL  should  meet  the 
needs  of  a  wide  range  of  national  systems,  while  C-BML  should  improve  the  sophistication  of  what  it  can 
represent  and  while  making  it  easier  to  use.  Based  on  success  thus  far,  a  coordinated  effort  should  continue 
toward  that  goal. 

Based  on  the  results  and  findings  of  the  MSG-085  a  new  TA  is  required  to  achieve  the  recommendations  set  out 
below. 


7.1  OPERATIONALISE  MSDL  AND  C-BML  STANDARDS 

One  of  the  aims  of  the  C2S1M  community  is  to  raise  the  Technical  Readiness  Level  (TRL)  of  the  capability  to 
TRL  7.  To  achieve  this  operationalisation  of  C2S1M  in  its  current  form,  which  includes  C-BML  and  MSDL 
standards,  would  be  an  important  first  step.  This  implies  the  integration  and  testing  of  national  C2S1M 
interoperability  products  that  implement  current  C-BML  and  MSDL  standards  and  also  their  utilisation  during 
multinational  or  coalition  events.  The  transfer  of  these  products  to  the  operational  community  will  facilitate  the 
familiarisation  of  these  technologies  by  the  end-users. 


7.2  EDUCATE  BROADER  COMMUNITY  ON  C2SIM  TECHNOLOGY 
EMPLOYMENT 

There  is  a  need  to: 

•  Engage  with  industry,  academia  and  government  in  the  fonn  of  NATO/Industry  workshops,  conferences, 
lectures  and  demonstrations. 

•  Participate  in  one  or  more  coalition  exercises  to  further  demonstrate  the  utility  of  C2S1M  to  the  military 
users. 
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7.3  ADVANCE  C2SIM  INTEROPERABILITY 

It  is  important  to  continue  progress  in  the  development  of  the  C2SIM  technology  and  their  standardisation. 
This  will  require  effort  to: 

•  Capture  additional  stakeholder  requirements  for  C2SIM  interoperability; 

•  Develop  extensions  to  cover  additional  national  and  domain  specific  requirements; 

•  Develop  a  unified  C2SIM  model; 

•  Develop  a  C2SIM  ontology,  advanced  grammar  and  business  rules; 

•  Define  a  set  of  reference  C2SIM  services;  and 

•  Develop  a  C2SIM  DSEEP  overlay. 

7.4  SUPPORT  NEXT  GENERATION  OF  C2SIM  INTEROPERABILITY 
STANDARDS  DEVELOPMENT 

After  these  technologies  have  been  validated  by  operational  use,  they  need  to  be  turned  over  to  SISO  for 
standardisation.  The  new  SISO  C2SIM  standard  then  becomes  a  candidate  for  standardisation  as  a  NATO 
STANAG. 
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A.l  APRIL  2011  -  BML  RESEARCH  SYMPOSIUM 


8:00 

Introduction  and  Purpose  of  BML 

Stan  Levine 

8:15 

KEYNOTE  Address 

On  BML:  * The  oxen  are  slow, ;  but  the  Earth  is  patient" 

A  sponsor's  perspective  on  BML  development  and  application 
slides 

Dr.  Amy  Henninger 

08:45 

Operational  Use-cases  for  BML 

slides  video 

Jens  Inge  Hyndoy 

09:15 

C-BML  Grammar,  Ontology  and  French  Military  Requirements  Jean-Gabriel  Herbinet 
slides 

09:45 

Coffee  break 

10:15 

An  Operational  Perspective  on  BML 

slides 

COL  Robert  Kewley 

10:45 

Coalition  BML  Agreements/Activities 

MSG-085  Standard za ton  for  C2-Simuiatiofl  Interoperation 

UK-FRA  BML  activity  caJled  SAFIR 

BML  cofaboration  between  Germany  and  France 

NLD-NOR  BML  coiaboration  using  MAKs  VR  FORCES 
slides 

Lionel  Khimeche 

11:15 

Grammar  Research  That  Supports  SISO  C-BML  Phase  2 

slides  C2LG  Soecification 

Bastian  Haarmann 

11:45 

Battle  Command  Activities  in  BML 

slides 

Ted  Troccola 

12:15 

Lunch  Break 

13:15 

A  Platform-Independent  JC3IEDM  as  a  Semantic  Reference 
for  Future  Interoperability  Solutions 

slides 

Nico  Bau 

13:45 

Aligning  C-BML  and  MSDL 

slides 

Rob  Wittman 

14:15 

Coalition  Battle  Management  Services 

slides  video 

Saikou  Diallo 

14:45 

Open  Source  Software  for  Battle  Management  Language 
slides 

Mark  Pullen 

15:15 

Coffee  break 

15:30 

On  the  Use  of  the  Web  Ontology  Language  (OWL) 
for  C-BML  Standards  Development 
slides 

Kevin  Gupton 

16:00 

Using  BML  in  Support  of  UAV  Training  and  Experimentation 

slides 

Kevin  Heffner 

16:30 

Scaling  to  the  Enterprise, 

Challenges  in  Scalable  BML  Applications 

slides 

Jeff  Abbott 
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A. 2  I/ITSEC  2011  DEMONSTRATION 


•  Future 


Concept  Development 
&  Experimentation 
Acquisition 


Training,  Mission  Rehearsal 
Decision  Support 


C2-simulation  interoperation  supports 
key  military  areas  of  interest: 

•  Force  Readiness; 

Support  for  Operations;  and 


* 

#1viSG-085\ 

|  C2-  Simulation  J 

V  Interoperation  ) 

?  s:  c-bml  ki 
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Standardizing  C2-simulation  interoperation 
provides  the  following  benefits: 

•  Enhanced  realism  &  overall  effectiveness 

•  Decreased  cost  &  workload 
►  Reduced  preparation  time 


1  DISTRIBUTED  TRAINING 


COALITION  TRAINING  CAPABILITIES 

Combined  C2-Simulation  Initialization 
Automated  Order  Execution 
Automated  Reporting 

CK 


1  Simulation  Node 
•  C2 Node 

Coalition  Services 


TRAINING  VIGNETTES 

Air  Reconnaissance 
Combined  Ops  with  Logistics 
Ground  Maneuver 
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A.3  SEPTEMBER  2012  -  BML  SYMPOSIUM  AGENDA 

Agenda 

08:15  -  08:30  Introduction  -  Dr.  Stan  Levine 
Sim  Research 

Invited  talks  focusing  on  new  technologies  with  the  potential  of  supporting  simulation  systems  by 
using currentand  future  BMLeffortse.g.  MSDL/C-BMLconvergence  and C-BMLPhase  2and  beyond. 
The  viewpoints  from  the  simulation  side,  doctrine,  technology,  methods  etc.  adapting  into  legacy 
systems,  developing  new  systems  etc. 

08:30-09:00  MSDLVersion  2  and  C-BMLConvergence  Dr.  Rob  Wittman,  MSDL  PDG  Co-Chair 

09:00-09:30  BMLbetween  simulations.  Jerome  Martinet(MASAGroup) 


C2  Research 

Invited  talks  focusing  on  new  technologies  with  the  potential  of  supporting  C2  systems  by  using 
current  and  future  BMLeffortse.g.  MSDL/C-BMLconvergence  and  C-BMLPhase  2  and  beyond.  The 
view  point  is  from  the  C2  side,  technology,  methods  etc. 


09:30-10:00 

10:00-10:30 

10:30-11:00 


Operational  requirements forC-BMLand  systems  initialization. 

Lionel  Khimeche,  DGA  (French  MOD) 


Break 

OneSAF  Mission  Command  Integration.  AmitKapadia,  PEOSTRI/CERDEC 


Infrastructure  Research 

Invited  talks  focusing  on  new  technologies  with  the  potential  of  supportingthe  underlying  needs  of 
BMLfroma  generic  perspective. 

11:00-11:30  Strategies  for  Future  MSDLVersion  2  and  C-BMLPhase  2  Alignment 

Dr.  Kevin  Heffner,  C-BML  Phase  2  DG  Editor 


11:30-12:00  A  Standards  Development  Framework  for  C-BML  Phase  2  and  Beyond 

Kevin  Gupton,  ARL:UT  &  Dr.  Kevin  Heffner 


12:00-13:30  Lunch 


13:30-14:00 

14:00-14:30 

14:30-15:00 


Interoperability  solutions  with  BML.  Jerome  Martinet  (MASA  Group) 

-AdvancesinopensourcesoftwareforBML  Dr.  MarkPullen, GMU 

-CBMS:  A  System  of  Systems  Interoperability  Enabler  Dr.  Saikou  Diallo,  VMASC 


15:00-15:30  Break 
Wrap-up: 

15:30  - 16:30  Summarize  the  presentations  and  to  pinpoint  three  challengesforthe  three  domains 
listed  above.  (Disussions)  Dr.  Stan  Levine 
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Nov  2012  C2-Sim  Interoperability  Workshop 


Military  requirements: 

Enable  and  enhance  command  post  forces  readiness  and 
support  to  operations. 

Problem  statement: 

Need  cost-effective,  efficient,  way  to  connect  C’2.  simulation 
and  autonomous  systems  in  order  to: 

•  Enhance  realism  &  overall  effectiveness 

•  Decrease  cost  and  workload 

•  Reduce  preparation  and  response  time 

Solution: 

Standardize  exchange  of  digitized  military  information  for  C2- 
Sim  interoperation. 


WORKSHOP  AGENDA 


10:00-10:15 

10:15-11:15 

11:15-12:15 

12:15-13:15 

13:15-14:30 

14:30-15:15 

15:15-15:45 

15:45-16:00 


Welcome  &  Introductory  remarks 
Infrastructure  CIG  Debrief 
Maritime  Operations  CIG  Debrief 

Lunch 

Land  Operations  CIG  Debrief 
UAV/Air  Operations  CIG  Debrief 
Joint  Mission  Planning  CIG  Debrief 
Wrap-up 


MSG-085  CIG  Workshop,  Fairfax  YA 
November  28'11.  2012 
10:00  am-16:00  pm 
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NATO 
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C2  to  Simulation  Interoperability  Workshop 
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BACKGROUND:  The  NATO  Modelling  and  Simulation  Group  (NMSG)  efforts  include  a  wide  range 
of  activities  supporting  major  NATO  initiatives.  One  such  initiative.  MSG-085,  is  working  m  the  area  of 
interoperation  between  C2  and  Simulation  Systems  with  the  aim  of  achieving  a  "  train  as  you  fight  ” 
environment  in  support  of  NATO  operations.  Through  the  use  of  the  standardised  Coalition  Battle 
Management  Language  simulated  systems  will  be  able  to  exchange  orders  and  reports  with  real  C2 
Systems  m  distributed  exercises. 

The  MSG-085  Experimentation  Programme  is  a  key  component  to  the  Technical  Activity.  The  goal  is  to 
establish  a  capability  that  can  be  deployed  m  the  medium-term  and  that  will  improve  NATO  Forces 
effectiveness.  In  order  to  be  more  efficient,  MSG-085  is  divided  mto  Common  Interest  Groups  (CIGs) 
that  provide  dedicated  work  in  different  C2-snnulation  interoperation  technical  and  operational  areas, 
including:  Land  Ops:  Mantime  Ops;  UAV/Air  Ops:  Jomt  Mission  Planning:  and  C2-Sim  mfrastmcnire. 

MSG-0S5  COMMON  INTEREST  GROUPS:  Land  Operations  CIG  demonstration  focuses  on 
command  post  exercise  framing.  It  highlights  the  benefits  of  the  use  of  standards  to  save  LOC'ON 
resources  and  time  during  exerase  preparation.  Therefore,  the  demonstration  addresses  first  the  use  of 
an  effective  initialization  process  based  on  MSDL  of  systems  involved  for  the  exercises.  MSDL 
exchange  format  enrichments  rationales  and  contents  are  also  shared  .  Second,  the  demonstration  deals 
with  the  execution  of  an  operational  scenario  derived  from  YTKING  2011  training  exercise.  Hence,  it 
highlights  the  use  of  CBML  for  two  new  military  areas  that  are  logistics  and  artillery.  C’orrespondmg 
C'BML  schema  improvements  are  mtroduced.  In  addition,  the  demonstration  intends  to  prove  that 
CBML  is  also  relevant  for  C2  to  C2  exchange.  UAY  Air  Operations  CIG  will  focus  on  a  Jomt 
Training  Exercise  use-case  where  C-BML  is  utilized  m  several  ways:  1)  first  to  initialize  die  simulated 
aircraft  m  the  Jomt  Semi-Automated  Forces  (JSAF)  simulation  with  respect  to  the  Airspace  Control 
Order  (ACO)  and  Air  Tasking  Order  (ATO)  received  from  NATO  ICC  Air  Command  and  Control  (C2) 
System:  2)  control  the  execution  of  aircraft  behaviour  durmg  die  scenario  execution:  and  3)  to  provide 
the  means  for  the  simulation  to  update  the  C2  systems  via  standard  reporting  mechanisms.  The  default 
aircraft  behaviours  respect  the  Airspace  Control  Measures  (ACM)  as  specified  by  the  ACO  while 
executing  tasks  such  as:  Aenal  Refueling  (AAR),  Suppression  of  Enemy  Air  Defense  (SEAD). 
Offensive  CoimterAir  (OCA).  Defensive  C'ounterAir  (DCA).  Airbom  Early  Warning  (AEW)  and 
Tactical  Air  Reconnaissance  (TRAL).  The  Common  Operational  Picture  (COP)  of  the  Jomt  Automated 
Deep  Operations  Coordination  System  (JADOCS)  C2  system  is  updated  via  an  automated  reporting 
mechansim  that  receives  C-BML  reports  generated  by  the  simulation  Maritime  Operations  CIG  will 
demonstrate  the  mitial  capabilities  of  die  Maritime  C-BML  with  a  basic  Naval  scenario.  In  the  scenario. 
Coalition  Task  Force  (CTF)  401.  which  includes  diree  Task  Groups  consisting  of  frigates  vvidi  organic 
helos.  mine  hunters,  mine  sweepers  and  LPDs.  is  responsible  for  conducting  Maritime  Interdiction 
Operations  (MIO)  ashore  of  Oxelosund  to  control  maritime  traffic.  CTF  401  is  also  responsible  for 
supportmg  die  amphibious  forces  in  the  pre-landing  phase.  Allocated  task  units/task  groups  will  execute 
babysitting  operations  for  protectmg  Mme  Counter  Measure  (MCM)  forces  that  are  isolating  and 
clearing  the  obstacles  m  the  entrance  and  vicinity  of  die  harbor  Oxelosund.  CTF  401  protects  MCM 
forces  against  air  and  surface  threats.  Infrastructure  CIG  demo  will  be  cast  as  an  Air  Recon  in 
Bogaland'Motala  supportmg  several  variants  of  BML  and  CBML  within  OneSAF.  We  will  show  MSDL 
initialization  using  info  provided  from  a  C2  system  with  an  associated  CBML  files  as  well  as  other  files 
showing  the  power  and  flexibility  of  the  MSDL  extension  design.  This  will  be  followed  up  with  BML 
formatted  observation  and  location  reports  sent  from  OneSAF.  OneSAF  will  also  accept  and  respond  to 
BML  orders  via  the  GMU  server. 
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Concept  Development 
<£  Experimentation 
Acquisition 


Training ,  Mission  Rehearsal 


Decision  Support 
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C2-simulation  interoperation  supports 

key  military  areas  of  interest: 

•  Force  Readiness; 

•  Support  for  Operations;  and 

•  Future  Capabilities  Developments 
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Standardizing  C2- simulation  interoperation 
provides  the  following  benefits: 

•  Enhanced  realism  &  overall  effectiveness 

•  Decreased  cost  &  workload 

•  Reduced  preparation  time 


DISTAFF  OPFOR 
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f :  OALITION  LAND  FORCES  OPERATIONS^ 

•  C2  and  Simulation  consistent  initialization 

•  Automated  order  execution  including  logistics  & 

artillery  j®* 
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AV/AIR  OPERATIONS 

•  Sim  initialization  using  actual  ATO/ACO 

•  Integration  w/C’2IS  for  Tasking  and  Reporting 

dirt — ili 
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C2  to  Simulation  Interoperability  Workshop 


Military  requirements: 

Enable  and  enhance  command  post  forces  readiness  and 
support  to  operations. 

Problem  statement: 

Need  cost-effective,  efficient,  way  to  connect  C2.  simulation 
and  autonomous  systems  in  order  to: 

•  Enhance  realism  &  overall  effectiveness 

•  Decrease  cost  and  workload 

•  Reduce  preparation  and  response  time 

Solution: 

Standardize  exchange  of  digitized  military  information  for  C2- 
Sim  interoperation. 


WORKSHOP  AGENDA 

Standards  &  Infrastructure 

8:30  Coalition  Battle  Management  Language  (C-BML) 
9 :00  Military  Scenario  Definition  Language  (MSDL) 
9:30  C2-Sim  Communication  Infrastructure 

Military  Applications  &  Demonstrations 

1 0 :00  UAV/Air  Operations 
10:30  Land  Operations 
1 1 :00  OneS  AF  Air  Recon 


I/TTSEC  2012,  Orlando  FL 
December  5th,  2012 
8:30-11:30  am  Mtg  Room  W308C 


Contact  NATO  MSCO  staff  for  details 
msg@cso.  nato.  bit 
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Cl  to  Simulation  Interoperability  Workshop 


Background 


During  the  last  decade,  considerable  progress  has  been  made  in  establishing 
interoperability-enabling  standards  in  both  the  Command  and  Control  (C2) 
domain,  through  the  work  of  the  Multilateral  Interoperability  Programme  (MIP) 
and  within  the  M&S  community  through  the  efforts  of  the  Simulation 
Interoperability  Standards  Organization  (SISO). 


The  interoperation  between  command  &  control  information  systems  (C'2IS)  and 
simulation  systems  is  a  common  theme  in  the  transformation  of  modem  military 
forces.  This  is  required  to  support  the  military  enterprise  in  the  execution  of 
business  activities  and  mission  threads  such  as  operational  training,  information 
sharing  and  decision  support.  This  implies  the  ability  to  seamlessly  integrate 
C'2IS  and  simulation  systems  and  to  provide  the  means  for  a  meaningful  and 
unambiguous  information  exchange-  This  applies  to  systems  of  systems 
functioning  toward  a  common  goal  at  different  levels:  (1)  within  services.  (2) 
across  services  (i.e.  joint)  and  (3)  across  nations  in  a  multinational  or  coalition 
context. 

Enabling  such  information  exchange  in  a  timely,  efficient  and  cost-effective 
manner  requires  a  standardized  language  and  interfaces  that  allow  C'2  and 
simulation  systems  to  interoperate.  This  the  scope  of  the  Coalition  Battle 
Management  Language  (C-BML)  being  developed  by  SISO. 


Use-case  scenarios  involving  information  exchange  across  C'2IS  and  simulation 
systems  often  require  a  pre-requisite  initialization  of  all  systems  that  is 
consistent  with  existing  simulation  and  or  operational  databases.  This  currently 
represents  a  significant  obstacle  to  C2-simulation  interoperation.  Approved  by 
SISO  in  200S.  the  Military  Scenario  Definition  Language  (MSDL)  also  has  been 
developed  as  a  standard  by  SISO  to  enable  C2IS-simulation  interoperation,  with 
regard  to  the  initialization  of  simulation  systems.  Version  2  of  MSDL  currently 
is  being  drafted  to  address  requirements  such  as  convergence  and  alignment  of 
MSDL  with  C-BML. 


ITT  SEC  2012,  Orlando  FL 
December  5th.  2012 
8:30am-ll:30  am 


Contact  NATO  MSCO  staff  for  details 
msg@cso.nato.int 
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14.  Abstract 

The  interoperation  between  Command  and  Control  (C2)  systems  and  simulation  systems  is  a 
common  theme  in  the  transformation  of  modem  military  forces.  This  is  required  to  support  the 
military  enterprise  in  the  execution  of  business  activities  and  mission  threads  such  as  forces 
readiness,  decision  support  and  acquisition.  This  implies  the  ability  to  seamlessly  integrate  C2  and 
simulation  systems  and  to  provide  the  means  for  a  meaningful  and  unambiguous  information 
exchange.  This  applies  to  systems  of  systems  functioning  toward  a  common  goal  at  different  levels: 
1)  within  services;  2)  across  services;  (i.e.  joint)  and  3)  across  Nations  in  a  multi-national  or 
coalition  context. 

In  2010,  the  NATO  Research  and  Technology  Organization  started  the  three-year  Modeling  and 
Simulation  Task  Group  “Standardisation  for  C2-Simulation  Interoperation”  to  assess  and  document 
the  C2  and  Simulation  interoperability  standards  developed  by  SISO  to  be  used  for  multiple  military 
applications.  This  final  report  documents  the  completed  work  of  this  Task  Group,  designated 
MSG-085.  It  includes  the  continued  progress  made  to  demonstrate  the  utility  of  C2-Simulation 
interoperability.  This  report  leverages  the  knowledge  of  C2-Simulation  experts  to  merge  current 
standards  towards  a  unified,  more  manageable  and  easier  to  deploy  C2SIM  interoperability. 
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